FS#47749 - [systemd] 228-3 does not create (update ?) utmp

Attached to Project: Arch Linux
Opened by jb (jb.1234abcd) - Thursday, 14 January 2016, 14:10 GMT
Last edited by Dave Reisner (falconindy) - Thursday, 14 January 2016, 19:40 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

First of all, on boot the /var/run/utmp is missing; I assume it should be ug+rw and owned by utmp group like
/var/log/wtmp:
$ ls -al /var/run/utmp
-rw-rw-r-- 1 root utmp 0 Jan 14 13:21 /var/run/utmp
so that xterm, uxterm, etc are also logged (in addition to tty1, etc, which do not require utmp group ownership).

According to utmp(5), wtmp(5):
NOTES
Unlike various other systems, where utmp logging can be disabled by
removing the file, utmp must always exist on Linux. If you want to
disable who(1), then do not make utmp world readable.

When I create /var/run/utmp manually, then the logging takes place:
$ w
14:28:22 up 1:08, 3 users, load average: 0.00, 0.01, 0.05
USER TTY LOGIN@ IDLE JCPU PCPU WHAT
jb tty1 13:57 24:28 36.09s 0.00s xinit /home/jb/.xinitrc -- /hom
jb pts/1 14:08 20:12 0.00s 0.00s bash
[jb@myhost ~]$ who
jb tty1 2016-01-14 13:57
jb pts/1 2016-01-14 14:08 (:0.0)

I assume it should be set up by systemd (systemd-logind.service ?; Note: pam_systemd(8), called by it, may not be
present even on a systemd system).

Lastly, I am a bit confused about this UTMP reference here (utmp and wtmp are different and located in different places):
$ cat /usr/lib/systemd/system/systemd-update-utmp.service
Description=Update UTMP about System Boot/Shutdown
...
RequiresMountsFor=/var/log/wtmp
...

I am not sure what this means:
$ systemctl status /usr/lib/systemd/system/systemd-update-utmp.service
● usr-lib-systemd-system-systemd\x2dupdate\x2dutmp.service.mount
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)

Additional info:
* package version(s)
libsystemd 228-3
systemd 228-3
systemd-sysvcompat 228-3

* config and/or log files etc.

Steps to reproduce:
as above
This task depends upon

Closed by  Dave Reisner (falconindy)
Thursday, 14 January 2016, 19:40 GMT
Reason for closing:  Not a bug
Additional comments about closing:  See comments: user error
Comment by Dave Reisner (falconindy) - Thursday, 14 January 2016, 14:28 GMT
tmpfiles is used to create /run/utmp on startup. Does /usr/lib/tmpfiles.d/systemd.conf exist for you? Does 'journalctl -b _COMM=systemd-tmpfiles' show anything (errors, in particular).

> I am not sure what this means [...]:
It means you can't use 'systemctl status' on a file, just a unit. You meant to type: `systemctl status systemd-update-utmp.service`.
Comment by Doug Newgard (Scimmia) - Thursday, 14 January 2016, 14:42 GMT
Is /var/run a symlink to ../run or did you change that?
Comment by jb (jb.1234abcd) - Thursday, 14 January 2016, 18:28 GMT
The /var/run/utmp missing was my fault - I incorrectly overwrote /usr/lib/tmpfiles.d/systemd.conf with my custom config.

Regarding the item "Lastly, I am a bit confused about this UTMP ...":
it seems to me that there should be two distinctive services (unit files) for utmp and wtmp updates.

There shoud be:
/usr/lib/systemd/system/systemd-update-wtmp-runlevel.service
/usr/lib/systemd/system/systemd-update-wtmp.service
with dedicated executable
/usr/lib/systemd/systemd-update-wtmp

and

/usr/lib/systemd/system/systemd-update-utmp.service
with dedicated executable
/usr/lib/systemd/systemd-update-utmp

The current (and future wtmp) unit file contains
RequiresMountsFor=/var/log/wtmp
which is described in systemd.unit(5) as
RequiresMountsFor=
Takes a space-separated list of absolute paths. Automatically adds
dependencies of type Requires= and After= for all mount units
required to access the specified path.

I am just wondering if similar in particular should apply to the new (future utmp) unit file as well
RequiresMountsFor=/var/run/utmp
because the type is configured as
$ cat /usr/lib/tmpfiles.d/systemd.conf
...
F! /run/utmp 0664 root utmp -
...
and described in tmpfiles.d(5) as
If the exclamation mark is used, this line is only safe of execute
during boot, and can break a running system. (...)
and
$ mount
...
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
...
and
$ ls -al /var/run
lrwxrwxrwx 1 root root 6 Sep 30 21:17 /var/run -> ../run
Comment by Dave Reisner (falconindy) - Thursday, 14 January 2016, 19:10 GMT
> The /var/run/utmp missing was my fault
So this is not-a-bug?

> it seems to me that there should be two distinctive services (unit files) for utmp and wtmp updates.
wtmp is updated on user login/logout and system boot (runlevels do not exist). I don't know how you'd make this into a service, or why it would make sense to do so. Regardless, it's not something for Arch to address, as this would need to be implemented upstream.
Comment by jb (jb.1234abcd) - Thursday, 14 January 2016, 19:35 GMT
The /var/run/utmp was not a bug.

> (...) I don't know how you'd make this into a service, or why it would make sense to do so (...)
Well, by the same reasoning there exist services today
/usr/lib/systemd/system/systemd-update-utmp-runlevel.service
/usr/lib/systemd/system/systemd-update-utmp.service
which are confusingly named and their unit files defined for one log file only.

Loading...