systemd depends so heavily on a files it can not reboot

["Jóhann B. Guðmundsson"]

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