systemd crashes on daemon-reexec if /run is full

[mbiebl]

Submission type

• Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

v232

Used distribution

Debian
This was originally reported as
http://bugs.debian.org/850074

In case of bug report: Expected behaviour you didn't see

systemctl daemon-reexec failing with a clear error message and systemd not aborting when /run is full

In case of bug report: Unexpected behaviour you saw

systemctl daemon-reexec on a system with a full /run leads to a crash of systemd

In case of bug report: Steps to reproduce the problem

# cat /dev/zero > /run/eatspace
cat: write error: No space left on device
# systemctl daemon-reexec
Broadcast message from systemd-journald@kenaz (Tue 2017-01-03 16:16:42 EST):

systemd[1]: Freezing execution.


Message from syslogd@kenaz at Jan  3 16:16:42 ...
 systemd[1]: Freezing execution.

[mbiebl]

The log contains

Jan  3 13:59:01 kenaz systemd[1]: Failed to serialize state: Input/output error
Jan  3 13:59:01 kenaz systemd[1]: Freezing execution.

When /run is full, a "daemon-reload" also fails with a rather unspecific error message

Jan  3 13:59:01 kenaz systemd[1]: Reloading.
Jan  3 13:59:01 kenaz systemd[1]: Failed to reload: Input/output error

[poettering]

I figure we could remove this issue by moving this over to memfd...

[poettering]

(But let's not kid ourselves: /run being full will necessarily mean a DoS, there's no way around that, as we use that for communication primitives and a lot of other stuff)

[vcaputo]

It would be reasonable to refuse attempting /run-dependant operations if it's full (or very nearly full) though, which leaves the user in a much better position than

Jan  3 13:59:01 kenaz systemd[1]: Freezing execution.

[poettering]

@vcaputo yeah, indeed we could add a small safety check that indeed refuses a reexec or reload if /run is overly full. good point.

[poettering]

Fix waiting in #5219. Please have a look