Bug 737292 - systemd update kills running services
Summary: systemd update kills running services
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-10 18:54 UTC by Michal Jaegermann
Modified: 2012-02-27 18:55 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-27 18:55:15 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.