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
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
|
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
Thursday, 14 January 2016, 19:40 GMT
Reason for closing: Not a bug
Additional comments about closing: See comments: user error
> 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`.
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
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.
> (...) 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.