Warnings after startx

pfr

After I run startx I get these two warnings:

trap: "SIGKILL" cannot be caught
xauth: file /home/dave/.serverauth.6460 does not exist

What led me to notice this was, while trying to configure slrn to access the new UnitedBSD news group I was experiencing another unrelated issue:

***Warning: Unable to find a unique fully-qualified host name.

@JuvenalUrbino has suggested I make some changed to my domain name in /etc/resolve.conf as well as specify domain in /etc/rc.conf and /etc/hosts while also removing ~/.Xauthority, ~/.serverauth* as well as rm -rf /tmp/.X*

I did all of this and, not only would I get the same warnings, but it would hang until I issued ^C after running startx on a fresh boot.

Now, there are two separate issues here. So not to confuse things, I've reverted my files in /etc to their previous versions where it does not hang but the two warnings persist (and I imagine they've always been there I just never noticed them).

Once I solve this, I will take another look at the warning given by slrn about my host name.

pfr

trap: "SIGKILL" cannot be caught
xauth: file /home/dave/.serverauth.6460 does not exist

This is normal, .serverauth.xxx doesn't exist because it's created exactly when the X-server starts.
Why the hell did you remove .Xauthority?
Check man xauth

rvp

pfr Other shells will (stupidly) let you trap the uncatchable signals SIGKILL and SIGSTOP. NetBSD's /bin/sh will rightly print a warning. Just ignore it (really, the Xorg folks should fix that startx script).

Post your /etc/hosts, /etc/resolv.conf and /etc/rc.conf

pfr

pin Why the hell did you remove .Xauthority?

I believe in an attempt to create a new one with modified domain settings.. Anyhow, it didn't work.

I expect @JuvenalUrbino will chime in to further explain, I just wanted to open this up to the forum.

So is the SIGKILL warning related to xauth and should I be concerned? If not then I'll move on.

JuvenalUrbino

pin Why the hell did you remove .Xauthority?

I was the one to provide him with such suggestion 😄 , since in the past I for one had to struggle against X hanging upon startup when invoked with the startx script. And, in each and every case, it was due to improper .Xauthority's ownership, permissions or credentials (e.g $HOME rsynced to a new system , $HOME shared across systems as a nfs mount, X unintentiinally launched as root, X launched over ssh with a restrictive umask, hostname changed).

pfr So is the SIGKILL warning related to xauth and should I be concerned? If not then I'll move on.

It can not be caught because it shouldn't be caught, only the kernel should be able to do it, check https://stackoverflow.com/questions/35569659/the-signals-sigkill-and-sigstop-cannot-be-caught-blocked-or-orignored-why

JuvenalUrbino https://superuser.com/questions/806637/xauth-not-creating-xauthority-file

JuvenalUrbino

pin https://superuser.com/questions/806637/xauth-not-creating-xauthority-file

I had implemented a similar solution for SSH X11 forwarding in this thread. As for executing X locally, the startx script takes care of that already . What I was referring to is the inability to overwrite .Xauthority by executing startx if the permissions of the file are messed up.

JuvenalUrbino I was referring to is the inability to overwrite .Xauthority by executing startx if the permissions of the file are messed up.

Just out of curiosity, why should they be messed up? In which case, why not just using chmod to correct those?
I'd expect even more trouble when .Xauthority doesn't exist or, am I just confused?

JuvenalUrbino

pin Just out of curiosity, why should they be messed up?

As I mentioned above, I faced similar issues with a NFS-shared home, as I was using the same hostname/username combination across the various client systems. Also if I remember correctly, changing the hostname will confuse xauth, since the X11 client library will no longer be able to find a matching cookie inside .Xauhority, resulting in a rejected connection¹.
Finally, if you're working as root in your user's HOME and launch a X session or you run startx with sudo, you'll generate a root-owned Xauthority. This is the sort of mistake one may make as *nix beginner,; in my case, it happened several years ago.

¹ and since @pfr had been changing the hostname associated with the loopback address inside /etc/hosts, I thought that to be the root of the X11 hanging problem.

pin I'd expect even more trouble when .Xauthority doesn't exist or, am I just confused?

Not quite; since the startx script already takes care of invoking xauth to generate a random authorization cookie and store it inside .Xauthority as a MIT-MAGIC-COOKIE-1 entry, using startx or xdm to lauch a local X11 session should always be enough to get credentials right. Things get trickier when launching a session remotely with Xnest or Xephyr over SSH or XMDPC, since you have to that manuallly.

pfr

rvp Post your /etc/hosts, /etc/resolv.conf and /etc/rc.conf

Note: I've commented out the parts that JU had suggested I put in my hosts file and my rc.conf file. Anything I change in my resolve.conf file gets overwritten by resolveconf. The suggested edit here was to put domain isp.dns.tld

/etc/hosts

#   $NetBSD: hosts,v 1.9 2013/11/24 07:20:01 dholland Exp $
#
# Host name database.
#
# This file contains addresses and aliases for local hosts whose names
# need to be resolvable during system boot; typically this includes only
# the address and FQDN for this machine's hostname.
#
# By default this file is consulted before DNS, so adding additional
# material here that then becomes out of date can lead to confusion.
# See nsswitch.conf(5).
#
::1             localhost hackbox.local hackbox
127.0.0.1       localhost hackbox.local hackbox
#::1             localhost localhost.sdf.org localhost
#127.0.0.1       localhost localhost.sdf.org localhost
#
# RFC 1918 specifies that these networks are "internal":
# 10.0.0.0        -   10.255.255.255  (10/8 prefix)
# 172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
# 192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

/etc/resolve.conf

# Generated by resolvconf
domain local
nameserver 192.168.1.1

/etc/rc.conf

#   $NetBSD: rc.conf,v 1.97 2014/07/14 12:29:48 mbalmer Exp $
#
# See rc.conf(5) for more information.
#
# Use program=YES to enable program, NO to disable it. program_flags are
# passed to the program on the command line.
#

# Load the defaults in from /etc/defaults/rc.conf (if it's readable).
# These can be overridden below.
#
if [ -r /etc/defaults/rc.conf ]; then
    . /etc/defaults/rc.conf
fi

# If this is not set to YES, the system will drop into single-user mode.
#
rc_configured=YES
critical_filesystems_local="OPTIONAL:/var OPTIONAL:/usr"

# Add local overrides below.
#
#domainname=sdf.org
hostname=hackbox
random_file=/etc/entropy-file
#securelevel=1
microcode=YES
#rtclocaltime=YES
rpcbind=YES
dbus=YES
famd=YES
powerd=YES
wpa_supplicant=YES
wpa_supplicant_flags="-B -D bsd -i iwn0 -c /etc/wpa_supplicant.conf"
dhcpcd=YES
dhcpcd_flags="-qM iwn0 -b"
npf=YES
xdm=NO
raidframe=NO
wscons=YES
sshd=NO
postfix=NO
ipv6addrctl=YES
ipv6addrctl_policy=ipv4_prefer
envsys=YES

JuvenalUrbino

pfr #::1 localhost localhost.sdf.org localhost
#127.0.0.1 localhost localhost.sdf.org localhost

Looks like I got confused by your /etc/hosts syntax while providing suggestions: why are there 3 names for each address? It should be:

address  hostname alias

P.S. the loopack address should always be 'localhost'.

This is why is better to ask for technical advise publicly rather than on private message; the mistake would have been spotted immediately. Also, this thread could have turned much shorter.

JuvenalUrbino

pfr # Generated by resolvconf
domain local

Is that your real resolv.conf? Usually resolvconf will associate the domain entry to your ISP's DNS if using dhcp on a home network.

rvp

pfr

As JU said, in /etc/hosts just leave the localhost entries alone (get the original lines from the base tar files).

In /etc/rc.conf change hostname to the FQDN:

hostname="hackbox.local"

As a test, after the system has come up, add a line like this to /etc/hosts:

192.168.68.151    hackbox.local    hackbox

Change 192.168.68.151 to whatever IP you got via DHCP, then see if you get the same error.

pfr

JuvenalUrbino This is why is better to ask for technical advise publicly rather than on private message

Agreed.

JuvenalUrbino Also, this thread could have turned much shorter.

Long threads are kinda my thing 😉

JuvenalUrbino Is that your real resolv.conf?

Sadly, yes.

JuvenalUrbino Usually resolvconf will associate the domain entry to your ISP's DNS if using dhcp on a home network.

Full disclosure: I have absolutely ZERO idea about network stuff. Once I had my system connected to the internet without issues I left it alone and forgot about it.

rvp As JU said, in /etc/hosts just leave the localhost entries alone (get the original lines from the base tar files).

Can you please point me to where the base tar files are kept?
All I changed from the standard entries was my hostname which was originally localhost
So the standard entry was probably: localhost localhost.local localhost
I think I'll give myself a new hostname this time around. I'm thinking ... cringebox 🤣

rvp Change 192.168.68.151 to whatever IP you got via DHCP, then see if you get the same error.

🤯 Once again, network configuration talk is like Arabic to me (hint: I don't speak Arabic)
I know how to turn my internet on/off and thats about it. Can you explain this step in a little more datail please?
ie. How can I ask my computer nicely to tell me what IP address DHCP has given me? ... I'm guessing ifconfig ?

Wow, really showing my weak points here. Is now a good time to remind everyone that I'm a Social Worker and not a trained IT/Sysadmin professional? 😆

PS. I'm happy to receive reading material on the subject that will help me to understand this better

pfr

rvp
This did the trick. Thanks.

After reading through that wiki I feel a little more confident in what I'm doing now. Cheers 🍻

rvp

pfr point me to where the base tar files are kept?

The etc.tar.xz should have the original.

pfr Can you explain this step in a little more datail please?

The Guide explains some of this. Chapter 24

pfr I'm guessing ifconfig?

Yes.

JuvenalUrbino

rvp The etc.tar.xz should have the original

I always keep a etc set for the running is version extracted at /usr/src or at /var/cache/sysupgrade, even though in the meantime, I've learned to backup original configs first. Few core things like rc.conf are always available at /etc/defaults. Then there's /usr/share/examples.

rvp

pfr This did the trick.

Until a reboot and an IP address change. Then you'll have to edit /etc/hosts again.
There are ways to fix this w/o manual intervention, but, that will require you to fiddle with your home router settings.
You game?

pfr

rvp
You suggesting I set up a static IP? I'm game if you are! 😆

Surely I could automate the manual part though with a script that is run at boot to edit my hosts file? Some awk/grep/sed magic ought to do it right? Even if I need to run the script manually after booting, it wouldn't be the end of the world.

rvp

pfr You suggesting I set up a static IP?

That's one way to do it: setup the router to hand out the same IP address based on a MAC address--but that you can handle on your own.

What I had in mind (if your dinky box is capable of it) is to have it assign your laptop any address it wants, but, associate the hostname we send it with that IP address. So you can change hackbox.X.Y to crackbox.X.Y and the router will answer DNS correctly. You can do this on standard Unix, but, I don't know if your router-box can.

In any case, this would mainly be router config. so better done off-board. This is United_BSD_, not Home-Router BBS. eh?