systemd depends so heavily on a files it can not reboot

[Adam Pribyl]

On Wed, 10 Jul 2013, "Jóhann B. Guðmundsson" wrote:

> On 07/10/2013 12:32 PM, Karel Volný wrote:
>> Dne úterý, 9. července 2013 16:57:22 CEST, "Jóhann B. Guðmundsson" 
>> napsal(a):
>>> No need too, Bill will just close this WONTFIX and reach through the 
>>> screen and smack you on the back of your head or Václav will just 
>>> find you with something to throw at you, either way you need to find 
>>> a helmet and start running 
>>
>> I don't think that asking at least for a link to formal decision about 
>> the change deserves any smacking ... we're talking about Red Hat's 
>> Bugzilla, not about GNOME's instance
>>
>
> The fact is that Adam Pribyl has just been lucky not experiencing that 
> with the other init system neither him nor you have ever pointed to the 
> actual regression but I'm very eager to read you comparison on sysv init 
> or upstart for that matter handling of a reboot situation when dealing 
> with file corruption of their relevant files in comparison with systemd 
> and how that is somehow being handled differently now then it has been 
> in the past which is why his  ( Adam P ) bug report against systemd got 
> closed wontfix any magic key combo wont fix corrupted system files no 
> matter how you wish for it.

Please do not take me wrong, but I do not want magic key to fix a 
corrupted filesystem. It just looks weird to me, that pressing "magic key" 
with systemd could do absolutely nothing, which is not something I was 
used to. Also I argue for the "magic key" to do at least something like 
TERM and KILL or sync and reboot.

You are right there is no analysis of init vs. systemd in case of 
corruption, let me try a few points:

1. init has one inittab config (rc scripts are not a something init hard 
depends on), that was cached vs. systemd has a miriad of crossdependet 
units that are not cached. Init survives the damage of inittab (or rc 
scripts) without issue, systemd not (while it looses just some of its 
functions depending on a files beeing corrupted).

2. damage of binaries like reboot probably has no impact on init ability 
to send TERM and KILL signal to all processes efectively limiting any 
further writes to (any) filesystem. On systemd system all those files link 
to one binary - systemctl, not sure so far, how critical this is for 
systemd.

I am not a systemd hater, I am just triing to point to something that is a 
systemd weaknes and could be somehow fixed (e.g. by caching the unit files 
or implementing failover magic key). It looks to me, that as systemd is 
accumulating more and more functions, it is getting a bigger single point 
of failure.

> JBG


Adam Pribyl