On 07/08/2013 12:03 PM, Adam Pribyl wrote:
I've hit very unpleasant trouble - my ext4 rootfs gots crazy and I had
a thousands of "multiply claimed blocks" files. This revealed to me
one systemd weakness - it depends so heavily on a files on a rootfs,
it can not, in case they are damaged, do its basic function - allow to
login and control and shutdown processes.
This really seems like a problem to me, because in case, there is
something wrong with the (remote) system, the least thing you want is
to not be able to login because systemd is missing some (non esential)
files. OK you may say - you can not login remotely - but you can not
login even localy and also an attempt to reboot the machine with years
working "ctrl-alt-del" is not working because e.g.
@ctrl-alt-del.target is missing.
So you are complaining not being able to connect to a ( remote ) host
with filesystem corruption and the base/cores OS files one of those that
are corrupted.
This really looked like a bug to me
https://bugzilla.redhat.com/show_bug.cgi?id=981877
but it is a feature.
That systemd requires a working rootfs like so many other things in the
OS sounds neither a bug nor a feature but what is to be expect.
So to avoid the worst - the need to interrupt the power and risk the
damage to all other mounted file systems, I'd like to open a
discussion on enabling the sysrq in Fedora by default to work around
this feature: https://bugzilla.redhat.com/show_bug.cgi?id=982200
No need to open a discussion. SysRq is disable for are a reason and what
you are propose allows anyone that sits at the keyboard to kill all
process,reboot without syncing or authorization and all because you got
a corrupted filesystem.
I'm pretty sure Bill will close this bug as a wontfix in a jiffy, if not
anyone from the security team will.
JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
