"who" and "users" not reporting anything

kcirick · 01-18-2016, 08:37 PM

I was just playing around when I noticed that "who" and "users" command, which are supposed to show currently logged in accounts, return nothing. (No errors, just nothing). At the least, I should expect my current username

How do I fix this? I believe these are part of coreutils package.

rtmistler · 01-18-2016, 10:53 PM

First I'd find out what gets invoked when you run those commands.

Code:

$ which who
$ which users

Are they launched from something like a Busybox binary? Are they symbolic links, and if so; what do those links point too? From each of those commands you should be able to get help by doing something like:

Code:

$ who --help
$ users --help

And see what gets reported there. Either the binaries are broken, some link is pointing to nothing, or some other thing.

Keith Hedger · 01-19-2016, 05:46 AM

Works here

Code:

keithhedger@LFSHal:~-> who
keithhedger tty1         2016-01-19 11:32
keithhedger pts/0        2016-01-19 11:44 (:0)
keithhedger@LFSHal:~-> users
keithhedger keithhedger

Looks like somthing went wrong when building/installing core utils, try rebuilding/reinstalling.

Busybox is not part of a standard LFS/BLFS install.

kcirick · 01-19-2016, 06:46 PM

So it turns out I didn't have /var/run/utmp file. I had /var/log/{btmp,lastlog,wtmp}, as written at the bottom of Chapter 6.6 (I am using 7.8-Systemd: http://www.linuxfromscratch.org/lfs/...eatefiles.html). As soon as I created the file and rebooted, the who and users command worked as expected.

It says at the bottom of the chapter:

Code:

Note
The /run/utmp file records the users that are currently logged in. This file is created dynamically in the boot scripts.

But in Systemd versions, there are no "boot scripts", so it doesn't get created? or am I missing something?

Keith Hedger · 01-19-2016, 06:48 PM

You do realize that the current LFS version is 7.8, you are using quite an old version.

kcirick · 01-19-2016, 07:13 PM

Quote:

Originally Posted by Keith Hedger

You do realize that the current LFS version is 7.8, you are using quite an old version.

... and I am using version 7.8-Systemd

Keith Hedger · 01-19-2016, 07:16 PM

Quote:

Originally Posted by kcirick

... and I am using version 7.8-Systemd

You edited your post, previously it was pointing out a possible error in 7.1/7.2 hence my post.

kcirick · 01-19-2016, 07:19 PM

Quote:

Originally Posted by Keith Hedger

You edited your post, previously it was pointing out a possible error in 7.1/7.2 hence my post.

Yes, I realized I was wrong. I edited it as soon as I realized, but you were quicker at reading it :-)

Anyway, the root of the issue still stands: Does the systemd version need the /var/run/utmp file manually created in Chapter 6.6?

Keith Hedger · 01-19-2016, 07:22 PM

Yeah was a bit confusing, sorry don't know and don't want to know about systemd, but maybe systemd does need this file, not at my machine at the mo but I will check tomorrow to see if its on my machine, I'll be back.

Keith Hedger · 01-20-2016, 05:50 AM

Just had a look my system also has this file (utmp) but it is created on startup via the cleanfs script like so

Code:

:> /var/run/utmp

if grep -q '^utmp:' /etc/group ; then
	chmod 664 /var/run/utmp
	chgrp utmp /var/run/utmp
fi

I guess systemd isn't doing this, this is part of the sysv init scripts here:
http://www.linuxfromscratch.org/lfs/...otscripts.html

Guess you will have to fudge it.

Krejzi · 01-20-2016, 02:36 PM

Quote:

Originally Posted by kcirick

Yes, I realized I was wrong. I edited it as soon as I realized, but you were quicker at reading it :-)

Anyway, the root of the issue still stands: Does the systemd version need the /var/run/utmp file manually created in Chapter 6.6?

/run/utmp is there on my system. It's created at boot by systemd-tmpfiles service.

Code:

/usr/lib/tmpfiles.d$ grep utmp *
systemd.conf:F! /run/utmp 0664 root utmp -

$ ls -l /run/utmp
-rw-rw-r-- 1 root utmp 1152 Jan 20 13:50 /run/utmp

Keith Hedger · 01-20-2016, 03:09 PM

Maybe the OP just accidently erased it then ran who and users, if as you say systemd creates it, or maybe somthing happend to the permissions?

kcirick · 01-20-2016, 10:02 PM

Quote:

Originally Posted by Krejzi

/run/utmp is there on my system. It's created at boot by systemd-tmpfiles service.

Code:

/usr/lib/tmpfiles.d$ grep utmp *
systemd.conf:F! /run/utmp 0664 root utmp -

$ ls -l /run/utmp
-rw-rw-r-- 1 root utmp 1152 Jan 20 13:50 /run/utmp

So I have the same thing. Then I checked whether /var/run was symlinked to /run. It turns out it is not. Should /var/run not be a symlink to /run ? I must have messed up somewhere but can't pinpoint which chapter this corresponds to.

Keith Hedger · 01-21-2016, 05:25 AM

Code:

keithhedger@LFSHal:~-> file /var/run
/var/run: symbolic link to /run

kcirick · 01-21-2016, 08:31 AM

I think I know what went wrong.

I install BLFS stuff using a script that makes a pseudo-package using tar. The script then installs (untar) into the system. If the install script tries to create a directory in /var/run, then it might destroy the symlink to /run (something like this happens with /usr/lib64, which should be a symlink to /usr/lib). I see in my /var/run directory cups-related stuff, so I'll have to check if that is the problem.

So would it be safe to copy the stuff that is currently in /var/run to /run, then relink /var/run to /run & reboot?