Re: systemd depends so heavily on a files it can not reboot
Dne středa, 10. července 2013 5:13:22 CEST, John Morris napsal(a): If you want sysrq and understand the implications you can enable it ... But then I remembered that if things have really went wrong you could boot with init=/usr/bin/bash. how do these advices help when the system is already so broken that it cannot reboot without help of sysrq or ctrl+alt+del combo? K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp ka...@jabber.cz :: Never attribute to malice what can :: easily be explained by stupidity. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
Thanks to all for their opinion. Now the last question: Could init sent on ctr-alt-del at least TERM and KILL to all processes in case, everything else failed ? Could systemd do that? My answers are YES and NO, but I may be wrong. For systemd I saw (after power interruption) in the log this: Jul 6 11:46:51 server systemd[1]: Failed to enqueue ctrl-alt-del.target job: Unit ctrl-alt-del.target failed to load: Not a directory. See system logs and 'systemctl status ctrl-alt-del.target' for details. This is the only response to ctrl-alt-del. You can of course see nothing, you can not login localy because: Jul 6 11:45:42 server systemd[1]: getty@tty1.service holdoff time over, scheduling restart. Adam Pribyl -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
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 K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp ka...@jabber.cz :: Never attribute to malice what can :: easily be explained by stupidity. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
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 For the first the enablement of sysrq has been discussed before ( check mailing list archives and bugzilla ) which btw Bill rejected at least once himself secondly ( and looking at the bug now has done so again ) and you did not even bother to backup your acclaimed regression when you reopen the bug and wanted every to get in their flamesuit Ctrl+Alt+Del has worked in the past now that doesn't work this is a regression 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. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On Wed, 2013-07-10 at 14:09 +0200, Karel Volný wrote: Dne středa, 10. července 2013 5:13:22 CEST, John Morris napsal(a): ... But then I remembered that if things have really went wrong you could boot with init=/usr/bin/bash. how do these advices help when the system is already so broken that it cannot reboot without help of sysrq or ctrl+alt+del combo? If it is a remote system you really should look into IPMI. If the system is really broken you really can't depend on ctrl-alt-del, SysRq or anything else to remaining working. Tell IPMI to toggle reset and hope the bootloader is still working, if it isn't repeat and boot rescue media from CD/USB, etc. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On Wed, 10 Jul 2013, John Morris wrote: On Wed, 2013-07-10 at 14:09 +0200, Karel Volný wrote: Dne středa, 10. července 2013 5:13:22 CEST, John Morris napsal(a): ... But then I remembered that if things have really went wrong you could boot with init=/usr/bin/bash. how do these advices help when the system is already so broken that it cannot reboot without help of sysrq or ctrl+alt+del combo? If it is a remote system you really should look into IPMI. If the system is really broken you really can't depend on ctrl-alt-del, SysRq or anything else to remaining working. Tell IPMI to toggle reset and hope the bootloader is still working, if it isn't repeat and boot rescue media from CD/USB, etc. All right, this is a next step - hard reset or power interruption. Normally what you do is (with increasing possibility of damage caused by reboot): 1. try to login remotely and find what is going on - reboot if necessary 2. try to login localy and find what is going on - reboot if necessary 3. try to reboot localy if login is not possible 4. hard reset the machine if login and reboots are not possible now what I experience is: 1. I could not login remotely (ssh was segfaultin, dono whyg) 2. I could not login localy, login just accepted my credentials and printed the login prompt again (systemd @getty was broken, could not be started) 3. I could not reboot localy (system @ctrl-alt-del was broken), system was running but absolutely no reaction to ctrl-alt-del 4. I only could do hard reset (IMPI, button, remote UPS whatever) In my opinion systemd should not ignore the option 3 completely. The keyboard input should at least attempt to TERM-KILL-sync-mount ro-halt. ATM if it has no ctrl-alt-del.target file it does nothing, just sits there leaving the system fully running, even thou local soft reset was requested and systemd knows that. Adam Pribyl-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 07/08/2013 09:39 AM, John Reiser wrote: 1. Install a userid whose login shell is /usr/bin/sync (or a script which does sync; sync) 2. Login as the sync user (twice, perhaps.) Running sync multiple times doesn't have any particular purpose on Linux. http://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 09/07/13 20:22, Gordon Messmer wrote: On 07/08/2013 09:39 AM, John Reiser wrote: 1. Install a userid whose login shell is /usr/bin/sync (or a script which does sync; sync) 2. Login as the sync user (twice, perhaps.) Running sync multiple times doesn't have any particular purpose on Linux. http://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync I sync I know what youmean! Seriously, thanks for the short history lesson, puts it all into perspective. Cheers, Gavin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
Dne pondělí, 8. července 2013 14:03:00 CEST, Adam Pribyl napsal(a): 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 +1 I took the courage to reopen that one, put on your flamesuits :-) K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp ka...@jabber.cz :: Never attribute to malice what can :: easily be explained by stupidity. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 07/09/2013 01:22 AM, Gordon Messmer wrote: On 07/08/2013 09:39 AM, John Reiser wrote: 1. Install a userid whose login shell is /usr/bin/sync (or a script which does sync; sync) 2. Login as the sync user (twice, perhaps.) Running sync multiple times doesn't have any particular purpose on Linux. http://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync Yes it does, because the rest of the system might not be quiescent during the first sync. The first sync disturbs the system with an impulse of activity. This may cause the rest of the processes to react in strange an wonderful ways, including creating many changed-and-unwritten blocks. The second sync cleans many of these. Of course this is a classic race condition which might never get resolved, but the probabilities are much more favorable after the second sync than after only the first. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 07/09/2013 10:41 AM, Karel Volný wrote: Dne pondělí, 8. července 2013 14:03:00 CEST, Adam Pribyl napsal(a): 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 +1 I took the courage to reopen that one, put on your flamesuits :- 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 mailto:vpav...@redhat.com ;) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On Mon, 2013-07-08 at 18:02 +0200, Adam Pribyl wrote: OK, so the systemd people say, it is perfecly fine you can not reboot via ctrl-alt-del (while it was always possible with init) and give me the advice to enable sysrq for the purpose, and sysrq people say, it's not for users, we will not enable it, it is dangerous. Now I have a server, what should I do there? Use debian, right. Pondered this thread before saying anything. I'm still trying to decide if systemd is an overall improvement or a regression myself. But no, this case isn't a reason to use Debian. The default in Fedora is the only sane one because it is the safe choice. If you want sysrq and understand the implications you can enable it if, and only if, it makes sense in your situation. That is better than expecting every user installing a system they won't have absolute physical control over to know about and remember to disable it. And I was going to agree that systemd makes a system a lot less reliable in the face of serious problems since it needs a lot more files to be intact for it to get to runlevel S, especially in a situation where you don't have the physical presence to insert rescue media. But then I remembered that if things have really went wrong you could boot with init=/usr/bin/bash. And if you are in a remote colo situation it is probably prudent anyway to ensure rescue media is always in a non-default boot location so you can regain control. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 07/09/2013 06:17 AM, John Reiser wrote: Yes it does, because the rest of the system might not be quiescent during the first sync. While that is certainly true, sync doesn't make the rest of the system quiescent. The first sync disturbs the system with an impulse of activity. This may cause the rest of the processes to react in strange an wonderful ways, including creating many changed-and-unwritten blocks. Now I can't tell if you're joking. The second sync cleans many of these. Of course this is a classic race condition which might never get resolved, but the probabilities are much more favorable after the second sync than after only the first. That's just silly. The only thing that would make a second sync flush any more blocks than the first one is continued system activity, or in other words, time. Syncing a second time may flush additional blocks, but no more blocks than if you's simply skipped the first. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 07/09/2013 01:42 AM, Gavin Flower wrote: I sync I know what youmean! :) Seriously, thanks for the short history lesson, puts it all into perspective. To be clear, I didn't write it. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
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
Re: systemd depends so heavily on a files it can not reboot
Sounds like an unfortunate situation that should be addressed by use of a Live system, which can repair or salvage data from the afflicted file systems. If repair is possible, job done. If not possible, solution is to re-install the operating system. Rather than invest serious effort to make systemd (or other components) tolerate various types of severe damage to the operating system, it seems better to learn how such damage happens, then devise ways to prevent this occurrence in the first place. If something is wrong, I much prefer to see an obvious symptom, even if there is no clear indication of the nature of the failure. I have too often had to clean up damage when a robust application found some way to continue, with unexpected semantics, after it decided it could tolerate some failure. Programs can be designed to detect certain failures and cope with them in reasonable ways. In your case with systemd, it is simply impossible to continue in a responsible way without the configuration data systemd requires, but lost when your file system was corrupted. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On Mon, 8 Jul 2013, Jóhann B. Guðmundsson wrote: 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. OK, so the systemd people say, it is perfecly fine you can not reboot via ctrl-alt-del (while it was always possible with init) and give me the advice to enable sysrq for the purpose, and sysrq people say, it's not for users, we will not enable it, it is dangerous. Now I have a server, what should I do there? Use debian, right. JBG Adam Pribyl-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 07/08/2013, Adam Pribyl wrote: On Mon, 8 Jul 2013, Jóhann B. Guðmundsson wrote: 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. OK, so the systemd people say, it is perfecly fine you can not reboot via ctrl-alt-del (while it was always possible with init) and give me the advice to enable sysrq for the purpose, and sysrq people say, it's not for users, we will not enable it, it is dangerous. Now I have a server, what should I do there? 1. Install a userid whose login shell is /usr/bin/sync (or a script which does sync; sync) 2. Login as the sync user (twice, perhaps.) 3. Press the hardware reset switch (or call your co-location provider and have them press it for you; or otherwise force a reboot via hardware means.) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 07/08/2013 09:02 AM, Adam Pribyl wrote: OK, so the systemd people say, it is perfecly fine you can not reboot via ctrl-alt-del (while it was always possible with init) and give me That seems unlikely that init would have been ok... Ctrl-alt-del switched to runlevel 6, so it still depended on files in /etc to be accessible, as well as the reboot executable to be intact. I have had several situations where filesystem issues blocked init from rebooting using ctrl-alt-del. In particular, if it couldn't unmount a filesystem for whatever reason, it wouldn't reboot. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On 07/08/2013 04:02 PM, Adam Pribyl wrote: On Mon, 8 Jul 2013, Jóhann B. Guðmundsson wrote: 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. OK, so the systemd people say, it is perfecly fine you can not reboot via ctrl-alt-del (while it was always possible with init) ??? The files on the system got corrupted so by all means explain to me how it was possible with init more so with then with systemd? And which previous init system sysv or upstart ? Or are you really saying you never manage to corrupt the legacy sysv init or upstart files so that's why it was always possible? and give me the advice to enable sysrq for the purpose, Yes you always wanted to make it possible to reboot on a corrupted filesystem and it was pointed as an option to achieve just that and sysrq people say, it's not for users, we will not enable it, it is dangerous. Yes enabling it is not a good default for the distribution however administrators and users themselves can enable if they want to while being aware of the security risks of doing so. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On Mon, 8 Jul 2013, Samuel Sieb wrote: On 07/08/2013 09:02 AM, Adam Pribyl wrote: OK, so the systemd people say, it is perfecly fine you can not reboot via ctrl-alt-del (while it was always possible with init) and give me That seems unlikely that init would have been ok... Ctrl-alt-del switched to runlevel 6, so it still depended on files in /etc to be accessible, as well as the reboot executable to be intact. I have had several situations where filesystem issues blocked init from rebooting using ctrl-alt-del. In particular, if it couldn't unmount a filesystem for whatever reason, it wouldn't reboot. OK, then I was probably just lucky all those years, or it is just by nature of systemd having so many files, that may influence this. Sorry to all to bother. Adam Pribyl -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
