Hide Forgot
Description of problem: After an update to systemd-35-1.fc16 from the previous systemd-34-1.fc16 it become immediately apparent that sshd is no longer running. Closer check showed that at least the following services active before an update are now dead: crond.service systemd-logind.service rpcbind.service sshd-keygen.service sshd.service In logs one can find pieces of that sort: systemd[1]: Reloading. rpcbind: rpcbind terminating on signal. Restart with "rpcbind -w" systemd[1]: rpcbind.service: main process exited, code=exited, status=2 systemd[1]: Unit rpcbind.service entered failed state. systemd[1]: rpcbind.service: control process exited, code=exited status=209 systemd[1]: Unit rpcbind.service entered failed state. 'systemctl status ...' is not much more illuminating either. Moreover first attempts of 'systemctl start sshd.service' failed too for one reason or another. With a remote system one would be immediately in a deep doo-doo. Version-Release number of selected component (if applicable): systemd-35-1.fc16 Expected results: Running services still running after systemd was updated. Additional info: I am not really sure why sshd-keygen.service was in this picture at all but I do have in logs from a time of this upgrade: systemd[1]: sshd-keygen.service: main process exited, code=exited, status=209 systemd[1]: Unit sshd-keygen.service entered failed state.
A check in logs showed that initially I missed the following which showed also after systemd update: systemd[1]: systemd-tmpfiles-clean.timer failed to queue unit startup job: Unit systemd-stdout-syslog-bridge.socket failed to load: No such file or directory. See system logs and 'systemctl status systemd-stdout-syslog-bridge.socket' for details. systemd[1]: Unit systemd-tmpfiles-clean.timer entered failed state. No such problems after a reboot.
Exit status 209 originates within systemd itself. It's EXIT_STDOUT. It means systemd was unable to setup the file descriptor for the service's stdout. Since systemd-35 the default stdout of services is redirected to syslog. Also in systemd-35 systemd-logger has been renamed to systemd-stdout-syslog-bridge and so has been the UNIX socket. The update from previous versions goes like this: 1. systemd-logger.socket is active, the UNIX socket is /run/systemd/logger. systemd knows to connect the stdout of services that want StandardOutput=syslog to this socket. 2. yum update # to v35 systemd gets re-executed with the new version in %post. 3. systemd-logger.socket is still active and listening, but the new systemd now expects a different UNIX socket: /run/systemd/stdout-syslog-bridge. systemd-stdout-syslog-bridge.socket is not active (it will start after reboot), so starting of services will be failing with EXIT_STDOUT. Perhaps an update scriptlet should start systemd-stdout-syslog-bridge.socket.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Is this still an issue or can this bug be closed?
(In reply to comment #4) > Is this still an issue or can this bug be closed? At least in systemd updates on Fedora 16 installation I did not notice anything of that sort, so I guess that this can closed, but what specifically fixed the issue I have no idea.
Ok closing this as fixed. Feel free to reopen this bug if you experience that issue again.