On Wed, Mar 22, 2017 at 12:50:01AM +0100, Michael Biebl wrote: > Please attach a complete journal log from the boot (journalctl -alb as root)
Done, but might not be helpful. I've (cleanly) rebooted since then, and now it's two *different* units that are failed. It looks like I've somehow ended up with two competing services: root@stretch:/home/test# systemctl list-units *syslog* UNIT LOAD ACTIVE SUB DESCRIPTION rsyslog.service loaded active running System Logging Service ● syslog.service loaded failed failed System Logging Service ● syslog.socket loaded failed failed Syslog Socket /lib/systemd/system/rsyslog.service is owned by rsyslog. However, I also found some other files/symlinks, none of which belong to any packages according to dpkg -S: lrwxrwxrwx 1 root root 35 Mar 21 19:54 /etc/systemd/system/multi-user.target.wants/rsyslog.service -> /lib/systemd/system/rsyslog.service -rw-r--r-- 1 root root 290 Mar 21 16:02 /etc/systemd/system/syslog.service -rw-r--r-- 1 root root 0 Mar 18 20:16 /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/rsyslog.service -rw-r--r-- 1 root root 95 Mar 18 20:16 /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also -rw-r--r-- 1 root root 0 Mar 18 20:16 /var/lib/systemd/deb-systemd-helper-enabled/syslog.service I don't know where /etc/systemd/system/syslog.service came from, but it is identical to the dpkg-installed /lib/systemd/system/rsyslog.service. I also don't know the significance of /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also, but it contains just these two lines: /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service Note also that since the initial reportbug, I've run systemctl disable rsyslog, followed later by enable rsyslog. This was after discovering it in the failed state several reboots in a row, so it shouldn't change anything.
journalctl-alb.txt.gz
Description: application/gzip
