Bug 737292

Summary:	systemd update kills running services
Product:	[Fedora] Fedora	Reporter:	Michal Jaegermann <michal>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	harald, johannbg, johannbg, kay, lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-02-27 18:55:15 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michal Jaegermann 2011-09-10 18:54:36 UTC

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.

Comment 1 Michal Jaegermann 2011-09-10 19:12:45 UTC

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.

Comment 2 Michal Schmidt 2011-09-22 21:13:20 UTC

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.

Comment 3 Fedora Admin XMLRPC Client 2011-10-20 16:25:32 UTC

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Jóhann B. Guðmundsson 2012-02-27 11:47:27 UTC

Is this still an issue or can this bug be closed?

Comment 5 Michal Jaegermann 2012-02-27 18:41:22 UTC

(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.

Comment 6 Jóhann B. Guðmundsson 2012-02-27 18:55:15 UTC

Ok closing this as fixed. 

Feel free to reopen this bug if you experience that issue again.