5 ms·

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 cycl

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.

dredmorbius 14y ago
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-6-seconds/ 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.
- jaylevitt 14y ago
  No, monit doesn't manage services. Monit tries to follow clues you've given it about what's running, it polls them once in a while, and if something appears to be not running (as measured by the instructions you've given it), it runs the one-liner you've given it that should start the thing up again. Monit does a thing that approximates managing a process, for certain values of "approximates", "managing", and "process". Supervisory process management is one of Linux's absolute weakest points. I cut my teeth on fault-tolerant HA minicomputers, and it pains me to think that 30 years later, we still don't have a way to say "make sure apache is always running. period." As a great blog pointed out, there is exactly one process that KNOWS when a service has stopped running, and it doesn't need .pid files or polling or anything else to tell it: process 1. I'm not a systemd advocate - I don't know enough about it, and we're using Ubuntu so I'll end up learning upstart anyway - but read this, it's way more eloquent that I can be: http://dustin.github.com/2010/02/28/running-processes.html http://dustin.github.com/2010/02/28/running-processes.html
  - dredmorbius 14y ago
    Fair points. And thanks, by the way, for actually advancing the discussion. Init can and does manage processes. Somewhat crudely, mostly via the 'respawn' directive. One thing it isn't particularly good at is telling if a process is doing something useful (say, serving out web pages successfully), but it will let you know that it's running. There was a semi-popular hack some years back to run sshd out of init (via respawn) to ensure you always had an SSH daemon on your box (Dustin mentions this). The downside is that while it will ensure sshd is running, it doesn't give you much flexibility over the process (you've got to edit inittab and 'init q' to make changes). What monit and kin can do, above and beyond process-level monitoring, is check that the service attributes of a process are sane. That a webserver, say, kicks out a 200 OK response rather than a 4## or 5## error, and restart the service if this isn't the case. Checking for correct operation can be more useful than simply verifying a process is running (though going too far overboard in defining "correctness" can also cause problems). For realtime/HA tools, attacking things on the single-system level is probably the wrong way to roll. You want a load balancer in front of multiple hosts with response detection -- is host A still up or not? Whether or not this ties into mitigation (restart) or alerting (notifications to staff) is another matter. There are also places other than init you can watch things from. /proc contains within it multitudes, including a lot of interesting/useful process state. Daemons can be written with control/monitoring sockets instrumented directly into themselves. Debuggers, strace, ltrace, dtrace, and systemtap all provide resolution inside a running process/thread. Creating something sane, effective, efficient, and sufficient out of all these tools ... interesting problem.
thaumaturgy 14y ago
I'm a daily laptop linux user, specifically Chakra Linux, http://chakra-linux.org/ http://chakra-linux.org/. My wish list goes something like this: better wireless drivers, improved sleep/suspend/hibernate/resume, better power management, a better package manager, more up-to-date applications ... At the very, very bottom of that list -- the very last item, so far at the bottom of the list that it's in danger of falling off entirely -- is "faster boot times". Dredmorbius is spot on, at least for me and my daily usage and the couple dozen or so servers that I'm responsible for. If things are so pooched that I have to reboot it, then it doesn't really matter to me anymore whether it takes 30 seconds or a minute to start up. I would much prefer not having to reboot it in the first place. Since Chakra was (I think) forked from Arch Linux, I'll have to check and see if they're gonna do this too. I hope not. (edit: none of this is intended as a criticism of Chakra's development team, who have been doing an amazing job of putting together a system that, despite its warts, I genuinely enjoy using every day.)
- jlgreco 14y ago
  I am not sure I understand how systemd's development inhibits progress of any of the things on your wish-list.
- rogerbinns 14y ago
  Note that a better way of saying things is that systemd deals with state changes a lot better. Booting is one big state change, but when you have a laptop you go through a heck of a lot of other state changes (suspend, hibernate, resume), docking, connectivity changes (eg wifi coming and going), storage added and removed etc. You may let other people use your system (more state changes). systemd can also ensure that only services you use actually use get started. For example printing is done as a server on Linux (cups) so systemd can ensure it doesn't start until you need it. This reduces power consumption. Because of the way systemd manages services it can also do a better job of isolating them and dealing with unexpected issues. For example if the print server crashes, or someone attacks it while in Starbucks you'll be better off. (Its chrooting is easier to use, as well as the way things are put into control groups.) All the things you list require developer time and attention. If systemd lets developers spend less time on startup scripts, then they will have more time to devote to the things on your list. (If you've ever had to write startup scripts you'll know how long it takes to develop and debug them.)
alrs 14y ago
I have a Debian laptop. ls -alh | wc -l returns 89. I can subtract "..", ".", and the "totals" lines, so that's 86 init scripts. Big O for 86 scripts is 86 * n, which simplifies to "n". I'm not concerned.
- dredmorbius 14y ago
  'ls -A | wc -l' will spare you having to account for the '.' and '..' lines. Omitting the '-l' (redundant for your case) also spares the "totals" line.
- Ralith 14y ago
  "Oh, and because each script runs in less than an hour, we can just say n = 1 hour, and that's a constant, so it simplifies down to instant!" Yeah, that's not how computational complexity works.
peterwwillis 14y ago
How long does it take your servers to finish POST? Shaving CPU cycles on boot is not something I ever worry about, because just getting to the boot loader takes minutes. Also, shell scripts rock for an init system language. It's a language that almost everyone knows and can debug without being a CS major. The only reason you 'have no idea what happened' is because the scripts are written poorly, and code in any language would be hard to debug if it's written poorly. Fork and exec, seriously? You're worried about functions that take microseconds to finish? Look again - the huge sleep cycles to wait for drivers to finish initializing takes up a lot more time. I have written my own init systems three times in three languages, and examined countless distros' versions. Trust me, shell is the best compromise.

dredmorbius 14y ago

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-6-seconds/ 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.

jaylevitt 14y ago
No, monit doesn't manage services. Monit tries to follow clues you've given it about what's running, it polls them once in a while, and if something appears to be not running (as measured by the instructions you've given it), it runs the one-liner you've given it that should start the thing up again. Monit does a thing that approximates managing a process, for certain values of "approximates", "managing", and "process". Supervisory process management is one of Linux's absolute weakest points. I cut my teeth on fault-tolerant HA minicomputers, and it pains me to think that 30 years later, we still don't have a way to say "make sure apache is always running. period." As a great blog pointed out, there is exactly one process that KNOWS when a service has stopped running, and it doesn't need .pid files or polling or anything else to tell it: process 1. I'm not a systemd advocate - I don't know enough about it, and we're using Ubuntu so I'll end up learning upstart anyway - but read this, it's way more eloquent that I can be: http://dustin.github.com/2010/02/28/running-processes.html http://dustin.github.com/2010/02/28/running-processes.html
- dredmorbius 14y ago
  Fair points. And thanks, by the way, for actually advancing the discussion. Init can and does manage processes. Somewhat crudely, mostly via the 'respawn' directive. One thing it isn't particularly good at is telling if a process is doing something useful (say, serving out web pages successfully), but it will let you know that it's running. There was a semi-popular hack some years back to run sshd out of init (via respawn) to ensure you always had an SSH daemon on your box (Dustin mentions this). The downside is that while it will ensure sshd is running, it doesn't give you much flexibility over the process (you've got to edit inittab and 'init q' to make changes). What monit and kin can do, above and beyond process-level monitoring, is check that the service attributes of a process are sane. That a webserver, say, kicks out a 200 OK response rather than a 4## or 5## error, and restart the service if this isn't the case. Checking for correct operation can be more useful than simply verifying a process is running (though going too far overboard in defining "correctness" can also cause problems). For realtime/HA tools, attacking things on the single-system level is probably the wrong way to roll. You want a load balancer in front of multiple hosts with response detection -- is host A still up or not? Whether or not this ties into mitigation (restart) or alerting (notifications to staff) is another matter. There are also places other than init you can watch things from. /proc contains within it multitudes, including a lot of interesting/useful process state. Daemons can be written with control/monitoring sockets instrumented directly into themselves. Debuggers, strace, ltrace, dtrace, and systemtap all provide resolution inside a running process/thread. Creating something sane, effective, efficient, and sufficient out of all these tools ... interesting problem.

thaumaturgy 14y ago

I'm a daily laptop linux user, specifically Chakra Linux, http://chakra-linux.org/ http://chakra-linux.org/. My wish list goes something like this: better wireless drivers, improved sleep/suspend/hibernate/resume, better power management, a better package manager, more up-to-date applications ... At the very, very bottom of that list -- the very last item, so far at the bottom of the list that it's in danger of falling off entirely -- is "faster boot times". Dredmorbius is spot on, at least for me and my daily usage and the couple dozen or so servers that I'm responsible for. If things are so pooched that I have to reboot it, then it doesn't really matter to me anymore whether it takes 30 seconds or a minute to start up. I would much prefer not having to reboot it in the first place. Since Chakra was (I think) forked from Arch Linux, I'll have to check and see if they're gonna do this too. I hope not. (edit: none of this is intended as a criticism of Chakra's development team, who have been doing an amazing job of putting together a system that, despite its warts, I genuinely enjoy using every day.)

jlgreco 14y ago
I am not sure I understand how systemd's development inhibits progress of any of the things on your wish-list.
rogerbinns 14y ago
Note that a better way of saying things is that systemd deals with state changes a lot better. Booting is one big state change, but when you have a laptop you go through a heck of a lot of other state changes (suspend, hibernate, resume), docking, connectivity changes (eg wifi coming and going), storage added and removed etc. You may let other people use your system (more state changes). systemd can also ensure that only services you use actually use get started. For example printing is done as a server on Linux (cups) so systemd can ensure it doesn't start until you need it. This reduces power consumption. Because of the way systemd manages services it can also do a better job of isolating them and dealing with unexpected issues. For example if the print server crashes, or someone attacks it while in Starbucks you'll be better off. (Its chrooting is easier to use, as well as the way things are put into control groups.) All the things you list require developer time and attention. If systemd lets developers spend less time on startup scripts, then they will have more time to devote to the things on your list. (If you've ever had to write startup scripts you'll know how long it takes to develop and debug them.)

alrs 14y ago

I have a Debian laptop. ls -alh | wc -l returns 89. I can subtract "..", ".", and the "totals" lines, so that's 86 init scripts. Big O for 86 scripts is 86 * n, which simplifies to "n". I'm not concerned.

dredmorbius 14y ago
'ls -A | wc -l' will spare you having to account for the '.' and '..' lines. Omitting the '-l' (redundant for your case) also spares the "totals" line.
Ralith 14y ago
"Oh, and because each script runs in less than an hour, we can just say n = 1 hour, and that's a constant, so it simplifies down to instant!" Yeah, that's not how computational complexity works.

peterwwillis 14y ago

How long does it take your servers to finish POST? Shaving CPU cycles on boot is not something I ever worry about, because just getting to the boot loader takes minutes. Also, shell scripts rock for an init system language. It's a language that almost everyone knows and can debug without being a CS major. The only reason you 'have no idea what happened' is because the scripts are written poorly, and code in any language would be hard to debug if it's written poorly. Fork and exec, seriously? You're worried about functions that take microseconds to finish? Look again - the huge sleep cycles to wait for drivers to finish initializing takes up a lot more time. I have written my own init systems three times in three languages, and examined countless distros' versions. Trust me, shell is the best compromise.