3 ms·

It's interesting to see examples of where systemd falls down, though I'd be interested to hear what the actual problem is. The Fedora bug report and linked pag

It's interesting to see examples of where systemd falls down, though I'd be interested to hear what the actual problem is. The Fedora bug report and linked page basically say "systemd fell over during an upgrade", but is this really a systemd problem or is it a Fedora problem?

digi_owl 12y ago
At this point in time they seem joined at the hip. I think a Pottering retort about Debian users complaining about the size of systemd was that it was introduced over time on Fedora. So if any distro should make systemd shine, it would be Fedora.
cesarb 12y ago
It's failing during an upgrade. My guess would be that it's a systemd problem, but one triggered by mixing systemd versions. Probably the systemctl from Fedora 21 does something that the systemd from Fedora 20 doesn't like. If that's the case, the bug might have even already been fixed in systemd upstream, but the fix wasn't applied to the older systemd in Fedora 20. The solution would be to backport the fix to Fedora 20's systemd package, so users who do a "yum update" before upgrading to Fedora 21 would have it. An alternative workaround might be to, immediately after unpacking the new systemd, send a SIGTERM to PID 1. According to http://www.freedesktop.org/software/systemd/man/systemd.html http://www.freedesktop.org/software/systemd/man/systemd.html, that signal directly tells PID 1 to re-exec itself, without using systemctl in the process. That would make PID 1 be the new systemd before anything tries to use the new systemctl.
siebenmann 12y ago
Almost any time PID 1 segfaults, it's PID 1's fault. With PID 1 being systemd, that makes it systemd's fault here. Based on gdb stack backtraces in the Fedora bug report and looking at the systemd code, it seems like some sort of memory corruption or overwrite, perhaps a use after free issue. The segfault itself comes from dereferencing a clearly invalid pointer and said pointer was obtained by dereferencing a structure field through another pointer, so you'd get exactly this result if the structure was overwritten with other data at some point. (In my grumpy sysadmin view, it is PID 1's fault even if the distribution is doing odd things around PID 1. Init processes need to be absolutely rock solid and extremely defensively coded, precisely because the world basically dies if they ever fall over.) (I am the author of the original post.)
- digi_owl 12y ago
  What i find interesting is that it is the traditional sysadmins that find fault after fault with systemd. On the other hand those that embrace it come from web/cloud development, with an eye towards virtualization and containerization. I think someone somewhere once compared it to pets vs cattle. Traditional servers are the pets of sysadmins. Groomed and cared for to make sure they never keel over unexpectedly. To the cloud "admins" (or maybe i should call them devops?) servers are cattle. they have X of them living in some cloud "farm" somewhere, and can order any number of them to be slaughtered and replace at the drop of a pin.

digi_owl 12y ago

At this point in time they seem joined at the hip. I think a Pottering retort about Debian users complaining about the size of systemd was that it was introduced over time on Fedora. So if any distro should make systemd shine, it would be Fedora.

cesarb 12y ago

It's failing during an upgrade. My guess would be that it's a systemd problem, but one triggered by mixing systemd versions. Probably the systemctl from Fedora 21 does something that the systemd from Fedora 20 doesn't like. If that's the case, the bug might have even already been fixed in systemd upstream, but the fix wasn't applied to the older systemd in Fedora 20. The solution would be to backport the fix to Fedora 20's systemd package, so users who do a "yum update" before upgrading to Fedora 21 would have it. An alternative workaround might be to, immediately after unpacking the new systemd, send a SIGTERM to PID 1. According to http://www.freedesktop.org/software/systemd/man/systemd.html http://www.freedesktop.org/software/systemd/man/systemd.html, that signal directly tells PID 1 to re-exec itself, without using systemctl in the process. That would make PID 1 be the new systemd before anything tries to use the new systemctl.

siebenmann 12y ago

Almost any time PID 1 segfaults, it's PID 1's fault. With PID 1 being systemd, that makes it systemd's fault here. Based on gdb stack backtraces in the Fedora bug report and looking at the systemd code, it seems like some sort of memory corruption or overwrite, perhaps a use after free issue. The segfault itself comes from dereferencing a clearly invalid pointer and said pointer was obtained by dereferencing a structure field through another pointer, so you'd get exactly this result if the structure was overwritten with other data at some point. (In my grumpy sysadmin view, it is PID 1's fault even if the distribution is doing odd things around PID 1. Init processes need to be absolutely rock solid and extremely defensively coded, precisely because the world basically dies if they ever fall over.) (I am the author of the original post.)

digi_owl 12y ago
What i find interesting is that it is the traditional sysadmins that find fault after fault with systemd. On the other hand those that embrace it come from web/cloud development, with an eye towards virtualization and containerization. I think someone somewhere once compared it to pets vs cattle. Traditional servers are the pets of sysadmins. Groomed and cared for to make sure they never keel over unexpectedly. To the cloud "admins" (or maybe i should call them devops?) servers are cattle. they have X of them living in some cloud "farm" somewhere, and can order any number of them to be slaughtered and replace at the drop of a pin.