| |||||||||||||
evolutionevolutionPosted Jan 29, 2013 7:49 UTC (Tue) by smurf (subscriber, #17840)In reply to: evolution by iabervon Parent article: Poettering: The Biggest Myths
>> suggests to me that, if you have some problem booting with systemd,
>> you get a special systemd debugger rather than the shell
Wrong. You get a shell.
Of course you'd then use systemctl commands to figure out what's wrong with your boot (start services individually, etc.), but that's a Good Thing – you want to start your bootup jobs in the same environment as when booting regularly, otherwise you might mask the problem.
(Log in to post comments)
evolution Posted Jan 29, 2013 8:53 UTC (Tue) by iabervon (subscriber, #722) [Link]
That's what I said: "However, the truth is that the shell is a good debugger, and it's what systemd actually provides, along with command-line tools to help debug systemd in particular."
Of your comment, my comment, systemd's actual behavior, and Lennert's original post, the only one that doesn't say that a shell plus systemctl is the right thing is Lennert's original post. That's why I said that *Lennert's writing* gives the wrong impression, and never said that systemd's *actual behavior* was wrong.
evolution Posted Jan 29, 2013 17:33 UTC (Tue) by raven667 (subscriber, #5198) [Link]
I think the point was supposed to be that there is a bunch of debug logging available in the systemd tool kit that isn't available in shell languages beyond 'set -x', maybe because in shell that doesn't show you the environment or working directory or other things or because debugging shell requires modifying the scripts to print out what they are doing rather than having built-in logging.
|
|||||||||||||