User: Password:
|
|
Subscribe / Log in / New account

evolution

evolution

Posted Jan 28, 2013 21:54 UTC (Mon) by smurf (subscriber, #17840)
In reply to: evolution by iabervon
Parent article: Poettering: The Biggest Myths

Well, with SysV init you remember to type "init=/bin/bash" for a basic root shell with which to attempt to fix stuff.

With systemd it's "systemd.unit=emergency.service". Somewhat more verbose, but I just set my alternate boot command line to it and I'm done.

>> systemd developers suggests that I can't get an environment
>> where services haven't been started in general,
>> but I can interactively start them

Who suggests that, and where? It's patently false. In an emergency.service environment you can "systemctl start foo.service" just like you normally do.


(Log in to post comments)

evolution

Posted Jan 28, 2013 23:27 UTC (Mon) by iabervon (subscriber, #722) [Link]

The statement:

"Some people try to imply that the shell was a good debugger. Well, it isn't really. In systemd we provide you with actual debugging features instead. For example: interactive debugging, verbose tracing, the ability to mask any component during boot, and more."

suggests to me that, if you have some problem booting with systemd, you get a special systemd debugger rather than the shell. This makes me worried, because I suspect that I might have problems unrelated to systemd, and might actually have to run the configuration tool for some other service that's needed in order to authenticate users, and a systemd-specific debugger might not make that feasible. 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. This is a particularly unfortunate statement, because it plays into the impression people have of systemd that the developers think the tools you understand aren't good and you need to use their new thing instead in order to work with systemd.

evolution

Posted Jan 28, 2013 23:56 UTC (Mon) by HelloWorld (guest, #56129) [Link]

> suggests [...] suspect [...] might [...] impression

Really, whom is this kind of discussion supposed to help? Grown-up people in computing ought to be able to make an argument based on facts.

evolution

Posted Jan 29, 2013 11:37 UTC (Tue) by nix (subscriber, #2304) [Link]

Facts?! In *this* industry?

Come on now. Why dirty a nice flamewar with nasty facts when you can have a stew of speculation and imputations of bad faith and attacks based on myths which are debunked in the very article this is a comment thread for?

The only thing we're missing is a nice car analogy! So let me provide one.

systemd's an Edsel with the trailer and aircraft-carrier-catapult attachments, sysvinit is a Peel Trident. (I just want a Volvo.)

evolution

Posted Jan 31, 2013 13:37 UTC (Thu) by ncm (subscriber, #165) [Link]

systemd is a flying submarine. sysvinit is a boat anchor with feathers.

evolution

Posted Jan 29, 2013 7:49 UTC (Tue) by smurf (subscriber, #17840) [Link]

>> 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.

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.

evolution

Posted Jan 29, 2013 16:18 UTC (Tue) by s0f4r (guest, #52284) [Link]

Just typing "emergency" will also drop you in emergency mode - it's shorthand for "systemd.unit=emergency.service"


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds