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
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
