Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arch Linux to migrate to Systemd

mailman.archlinux.org

Post reply on HN
Print view View original

11–20 of 129 posts

Re: Arch Linux to migrate to Systemd

#11

Post by dredmorbius »

Systemd takes a reliable, known, thoroughly debugged process (init, or various of its tweaks, including Ubuntu's upstart and Debian's insserv), and converts booting from a deterministic, predictable process to one that's inherently unpredictable.

And the stated objective? "To reduce boot times".

The best way to reduce boot times is to not boot. The reason I reboot systems is to return them to a known good state (or, very rarely, to perform a kernel upgrade).

On server hardware, I perform boots infrequently, and really, really, really want them to work right.

On end-user hardware, I perform boots infrequently, preferring to use suspend/restore to quiesce my systems (suspend to RAM, occasionally suspend to disk). That is a process which I'd like to have very thoroughly debugged and not give me any unhappy surprises (say: crash my video, e.g.: interactive session, lose track of drivers/hardware, especially wireless).

Systemd is the wrong answer to the wrong problem.

Much written better than I can: http://blog.mywarwithentropy.com/2010/10/upstart-better-init...

Systemd loses the huge transitivity of shell scripting, and puts you in the position of needing to acquire a novel skill at the one time you least need to be learning and most need to be applying: when your systems won't boot straight: https://lwn.net/Articles/494711/

I'm also not much surprised that Red Hat, who've had such a historic problem with consistency and reliable dependency management within their packaging system (as compared to Debian/Ubuntu) are proponents of this technology (hint: it's not the package format, it's the policy, or lack thereof). And now Arch.

Re: Arch Linux to migrate to Systemd

#12

Post by ajross »

bct wrote: post #8

It's too bad that opposition to changes like this is often expressed so trollishly. There's a real tradeoff here (of simplicity and of portability) that gets glossed over.

It's certainly true that the "minimal summary" of the features of systemd vs. sysvinit (or Busybox, or a BSD init script, which is even simpler) is hugely skewed against systemd. Understanding how systemd's process tracking works requires understanding cgroups, for example. Things that used to be one liners in a script ("mount hugetlbfs -t hugetlbfs /dev/hugepages") suddenly become first class "mount" objects with status. Systemd introduces a bunch of new jargon and new tools.

But at the same time systemd really does do much more than a classic "launch some stuff and call wait()" style init. And that stuff is pretty nice -- in a systemd world, no one needs to worry about writing a "daemon" any more. Any program that sits in a loop writing to standard output can be started, stopped and syslog'd.

And making this work isn't bad at all. You configure systemd with straightforward .ini file syntax and clear fields (e.g. "ExecStart=/path/to/my/program").

Basically it's complicated in structure (and the task of porting a whole distro to it strikes me as pretty scary) but simple in interface, and that's pretty much the right place to be. Most "systemd is too hard!" rants don't survive long past the initial implementation phase.

Re: Arch Linux to migrate to Systemd

#13

Post by adestefan »

dredmorbius wrote: post #11

Systemd takes a reliable, known, thoroughly debugged process (init, or various of its tweaks, including Ubuntu's upstart and Debian's insserv ), and converts booting from a deterministic, predictable process to one that's inherently unpredictable . And the stated objective? "To reduce boot times". The best way to reduce boot times is to not boot . The reason I reboot systems is to return them to a known good state (o…

> Systemd loses the huge transitivity of shell scripting, and puts you in the position of needing to acquire a novel skill at the one time you least need to be learning and most need to be applying: when your systems won't boot straight:

What about those that can't debug when a shell script breaks?

Your answer is going to be that they have no business administering a server where a shell script is an integral part of the system working.

Conversely, someone that can't debug when a system can't start that uses systemd has no business administering a server where systemd is an integral part of the system working. If your system uses systemd, then you're going to need to learn a new tool. Get used to it.

Re: Arch Linux to migrate to Systemd

#14

Post by ori_b »

adestefan wrote: post #13
dredmorbius wrote: post #11

Systemd takes a reliable, known, thoroughly debugged process (init, or various of its tweaks, including Ubuntu's upstart and Debian's insserv ), and converts booting from a deterministic, predictable process to one that's inherently unpredictable . And the stated objective? "To reduce boot times". The best way to reduce boot times is to not boot . The reason I reboot systems is to return them to a known good state (o…

> Systemd loses the huge transitivity of shell scripting, and puts you in the position of needing to acquire a novel skill at the one time you least need to be learning and most need to be applying: when your systems won't boot straight: What about those that can't debug when a shell script breaks? Your answer is going to be that they have no business administering a server where a shell script is an integral part of…

> What about those that can't debug when a shell script breaks?

Are they more able to debug when a systemd setup breaks? If not, it seems like a moot point to bring up. They're hosed either way.

Although I do have to say, I like the systemd model. The use of sockets to do process activation and thus doing away with almost all of the need for dependency management is pretty cool. I haven't used it enough to pass judgement, but the concept has the potential to be a good deal simpler than the init hackery we have now.

Re: Arch Linux to migrate to Systemd

#15

Post by bct »

ajross wrote: post #12
bct wrote: post #8

It's too bad that opposition to changes like this is often expressed so trollishly. There's a real tradeoff here (of simplicity and of portability) that gets glossed over.

It's certainly true that the "minimal summary" of the features of systemd vs. sysvinit (or Busybox, or a BSD init script, which is even simpler) is hugely skewed against systemd. Understanding how systemd's process tracking works requires understanding cgroups, for example. Things that used to be one liners in a script ("mount hugetlbfs -t hugetlbfs /dev/hugepages") suddenly become first class "mount" objects with st…

> Basically it's complicated in structure [...] but simple in interface, and that's pretty much the right place to be.

Thanks for posting this, this is a great analysis. It gets right to the heart of many of the disagreements I have with system design orthodoxy.

I think it's exactly the wrong place to be.

Re: Arch Linux to migrate to Systemd

#16

Post by FooBarWidget »

dredmorbius wrote: post #11

Systemd takes a reliable, known, thoroughly debugged process (init, or various of its tweaks, including Ubuntu's upstart and Debian's insserv ), and converts booting from a deterministic, predictable process to one that's inherently unpredictable . And the stated objective? "To reduce boot times". The best way to reduce boot times is to not boot . The reason I reboot systems is to return them to a known good state (o…

I'm sorry, but shell scripts suck as a language for booting the system. You need to fork() and exec() for almost anything non-trivial, wasting precious CPU cycles in the progress. It looks like every Linux distro has its own way to manage boot scripts. And when they fail, you have no idea what happened.

More importantly, init only handles starting and stopping of services. They don't manage services, like restarting them when they crash. Systemd can do that. The socket activation stuff also allows one to potentially save resources by not starting services until they're really needed.

The best way to reduce boot times is to not boot? Have you ever heard of "laptops" and "average users"? Even on my servers, a shorter boot time is welcome.

Re: Arch Linux to migrate to Systemd

#17

Post by dredmorbius »

adestefan wrote: post #13
dredmorbius wrote: post #11

Systemd takes a reliable, known, thoroughly debugged process (init, or various of its tweaks, including Ubuntu's upstart and Debian's insserv ), and converts booting from a deterministic, predictable process to one that's inherently unpredictable . And the stated objective? "To reduce boot times". The best way to reduce boot times is to not boot . The reason I reboot systems is to return them to a known good state (o…

> Systemd loses the huge transitivity of shell scripting, and puts you in the position of needing to acquire a novel skill at the one time you least need to be learning and most need to be applying: when your systems won't boot straight: What about those that can't debug when a shell script breaks? Your answer is going to be that they have no business administering a server where a shell script is an integral part of…

If they can't debug it, they can find someone who can, and that skillset is, I can guarantee you, going to be far more widely available than Systemd debugging fu.

On which point, specifically: when Debian breaks during initrd execution, the system is dumped to a shell, "dash", a POSIX-compliant shell. It doesn't have all the niceties of bash, but it's usable.

When a Red Hat system breaks during initrd execution, the system shell doesn't handle terminal IO. You literally can't even fucking talk to the damned thing. It's a scripting-only shell.

The kicker: the RHEL initrd shell is larger than dash.

Guess which of these two systems is easier to troubleshoot / debug / rescue in a pinch?

Re: Arch Linux to migrate to Systemd

#18

Post by dredmorbius »

FooBarWidget wrote: post #16
dredmorbius wrote: post #11

Systemd takes a reliable, known, thoroughly debugged process (init, or various of its tweaks, including Ubuntu's upstart and Debian's insserv ), and converts booting from a deterministic, predictable process to one that's inherently unpredictable . And the stated objective? "To reduce boot times". The best way to reduce boot times is to not boot . The reason I reboot systems is to return them to a known good state (o…

I'm sorry, but shell scripts suck as a language for booting the system. You need to fork() and exec() for almost anything non-trivial, wasting precious CPU cycles in the progress. It looks like every Linux distro has its own way to manage boot scripts. And when they fail, you have no idea what happened. More importantly, init only handles starting and stopping of services. They don't manage services, like restarting…

Exactly how precious are those CPU cycles? I mean, really. Can you put a dollar figure on them?

And then contrast that with the dollar figure for consultant / employee / remote hands time to figure out WTF went wrong?

There are numerous systems for managing services: monit is the best known, mon and several proprietary systems also exist. Nagios can tell you if the service is running or not (though it doesn't handle the start/stop logic).

These are small details and extensions on top of the existing SysV init foundation.

Ubuntu's boot time is already down to 8.6 seconds -- a restore from suspend is barely less than that (and restore from disk is considerably longer), though both restores preserve user state. You know, what applications / files you had open, and what was in them when you left off, positions of windows on your desktop. All that jazz. http://www.jamesward.com/2010/09/08/ubuntu-10-10-boots-in-8-...

The socket management is kind of nifty, but doesn't add a whole lot that xinetd didn't already offer (systemd does allow multi-socket services and d-bus-initiated services). I'm not convinced these couldn't be hacked into xinetd while preserving the simplicity and stability of init.

My desktop state (and its preservation) is worth a lot more than fast boot.

Yes. I've heard of inane gratuitous questions. As I said: if you're forcing average users to reboot with any frequency, you're Doing It Wrong.

Re: Arch Linux to migrate to Systemd

#19

Post by throwaway54-762 »

dredmorbius wrote: post #11

Systemd takes a reliable, known, thoroughly debugged process (init, or various of its tweaks, including Ubuntu's upstart and Debian's insserv ), and converts booting from a deterministic, predictable process to one that's inherently unpredictable . And the stated objective? "To reduce boot times". The best way to reduce boot times is to not boot . The reason I reboot systems is to return them to a known good state (o…

Your "much written better than I can" article is about Upstart, not Systemd. They're unrelated init daemons, and it seems like many of the complaints in the article relate specifically to upstart (event-triggered services with no dependencies, minimal scripting support, killing daemons, not all daemons managable by upstart) but do NOT apply to systemd. Systemd has service dependencies, support for old-style init scripts, and can stop daemons with arbitrary commands. Are you confusing the two init systems?

On the other hand, this would be nice: "There is no tool that will print out a dependency map." It's also pretty trivial to implement with a little shell script and graphviz.

Post reply on HN