Upgraded to 237-r1 and noticed that some unnits failed to start. systemd-logind and systemd-nspsawnd failed on the dbus.socket depenancy. dbus.socket was create in /var/run/dbus/ and therse units were looking for sockin in /run/dbus/. workaround was to mkdir /run/dbus ; mount -t bind /var/run/dbus /run/dbus
systemd-237/src/basic/def.h:#define DEFAULT_SYSTEM_BUS_ADDRESS "unix:path=/run/dbus/system_bus_socket" but sys-apps/dbus-1.12.2 has /lib/systemd/system/dbus.socket thusly; [Unit] Description=D-Bus System Message Bus Socket [Socket] ListenStream=/var/run/dbus/system_bus_socket sys-apps/dbus-1.12.2
My system also failed to allow logins today after upgrading to sys-apps/systemd-237-r1. The journal messages read: Failed to connect to system bus: No such file or directory coming first from systemd itself, then from systemd-logind. So it seems that the OP is right (don't like his fake name though). Note that /usr/lib64/pkgconfig/dbus-1.pc also has system_bus_default_address=unix:path=/var/run/dbus/system_bus_socket - if that should be changed it may be necessary to recompile other software linked to dbus-1. I don't know why systemd itself doesn't honor the path given in that configuration though. Downgrading to 236-r5 fixes the problem.
/var/run is supposed to be a symlink to /run. If it is not, your system was somehow broken at some point.
(In reply to Mike Gilbert from comment #3) > /var/run is supposed to be a symlink to /run. If it is not, your system was > somehow broken at some point. Thanks for the hint! After removing /var/run and making it a symlink to /run, I can now log in to the system under systemd-237-r1. I don't think something broke my system, I guess that the FS standard was not in effect when I first installed it more than 10 years ago... Hardware changed but i preferred not to install the system from scratch. I'm very happy that this is possible with Linux and would guess that many people pull images between computers this way. So I think there should be a check in effect whether such crucial assumptions are actually met, so that the system is not left in an inoperable state - in effect this was as bad as it can get, forcing me to boot from USB to revert systemd...
Confirmed! >=sys-apps/systemd-236 changes a number of it's paths (such as /var/run to /run and /usr/bin/systemctl to /bin/systemctl). This breaks sys-apps/dbus until sys-apps/dbus is re-emerged as it grabs systemd's pathways as it builds. Devs need to find a way to force sys-apps/dbus to be rebuilt when systemd gets updated.
Posting again because of Gentoo's bug tracker's buggy text formatting truncating the previous post: Confirmed! Greater than or equal to sys-apps/systemd-236 changes a number of it's paths (such as /var/run to /run and /usr/bin/systemctl to /bin/systemctl). This breaks sys-apps/dbus until sys-apps/dbus is re-emerged as it grabs systemd's pathways as it builds. Devs need to find a way to force sys-apps/dbus to be rebuilt when systemd gets updated.
(In reply to Rick Harris from comment #6) > Greater than or equal to sys-apps/systemd-236 changes a number of it's paths > (such as /var/run to /run and /usr/bin/systemctl to /bin/systemctl). systemd-236 does not implement any change to move files from /var/run to /run.
