| Summary: | sys-apps/systemd-237-r1 logind and other units FAIL to with start dbus file not found when the /var/run symlink is missing | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Lennar Pottering <9z3ozp+60yknq4bzh23c> |
| Component: | Current packages | Assignee: | Gentoo systemd Team <systemd> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | marci_r, slawomir.nizio, tsmksubc |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 648880 | ||
| Bug Blocks: | |||
|
Description
Lennar Pottering
2018-02-04 05:22:16 UTC
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. |
