RFC: a new init system for Arch

jf/ · 2007-04-03 22:51:58

hi guys, i've been thinking about this for a while, especially since after seeing what a real optimized init system can do for a distro (ala Annvix). Recently, somebody also suggested the use of upstart (http://bbs.archlinux.org/viewtopic.php? … 59#p238859), and i've been thinking that perhaps it's time to put forth this suggestion to the community, and get the devs in on this (discussion) as well.

What do u guys think of replacing and moving from the current BSD-init style (it's great, but there's more stuff out there!!!) to a better, "totally optimized", "rad" (excuse the slang, also known as "awesome") init system?

Here are my thoughts for the 2 that i've investigated...

1. Upstart (http://upstart.ubuntu.com/index.html)

Advantages:
- active, maintained code
- the idea of "events" is natural, intuitive, and as a model, fits the real world situation ("optimizing for the bootup process") very nicely
(although one could also argue that u could just as well call your events "dependencies" ala initng, if u dig deeper, u'll see that it's more than just that)

Disadvantages:
- looks set to become much more than just a simple 'init' replacement (see for eg., http://upstart.ubuntu.com/wiki/ComplexEventConfig [via https://launchpad.net/upstart from "Latest proposed features" section]), and violate the KISS principle of Arch??? (or is this still considered "simple enough"???):
-> looks set to replace cron, atd, and anacron, .... (http://upstart.ubuntu.com/faq.html#replace-cron)
-> looks set to almost (or could potentially become) a "total event system for Linux" (see the last 3 questions of the faq)

2. Runit (http://smarden.org/runit/)

Advantages:
- fits the KISS idea most definitely
- can be integrated very nicely with its 'supervise-like' replacements to help supervise ur services
- if u're a djb fan, u'll find urself going "woohoo!!!" You'll get the very same advantages that u get with djb's supervise system...

Disadvantages:
- if u're not a djb fan, u'll find urself going ....

Your comments and ideas, folks?

RobbeR49 · 2007-04-03 23:03:15

I think this has been brought up a couple times already, at least Upstart has.

http://bbs.archlinux.org/viewtopic.php?id=29679 & http://bbs.archlinux.org/viewtopic.php?id=25866 for instance

I think it falls under the "if it ain't broke, don't fix it" category. Personally I think Arch's init system works fine as it is.

jf/ · 2007-04-03 23:07:46

RobbeR49 wrote:

I think this has been brought up a couple times already, at least Upstart has.
http://bbs.archlinux.org/viewtopic.php?id=29679 & http://bbs.archlinux.org/viewtopic.php?id=25866 for instance
I think it falls under the "if it ain't broke, don't fix it" category. Personally I think Arch's init system works fine as it is.

ah, ok! didnt know that. Thanks for the note. I think to a certain extent, the "dont fix it if it aint broke" philosophy is good, but that generally only applies to perhaps complex situations, and is better bolstered if there is no clear or proven solution... In this case, i think the alternatives i've listed already are already shown as working, and working marvellously on other distros.

deficite · 2007-04-04 04:12:01

I've always wanted to experiment with alternate init systems. What's not really encouraging me to actively seek out this is the fact that Arch's init system is very fast due to its simplicity and the only way to speed it up would be to start caching stuff. Some members of the board have already experimented with that as well, you can search for it on these boards.

bwalk · 2007-04-04 07:49:47

Why? Why move? My init system is perfectly trimmed down to exactly what I need, it is fast, slick and simple. If yours is not you are making something wrong. The one and only complaint if have about the current init sys is that it is noch LSB compatible. But does this matter?

tomk · 2007-04-04 08:15:49

Some thoughts around this topic, as like others here, I find the current system meets my needs, and I have therefore not investigated alternatives.

A discussion like this will no doubt be interesting, and user suggestions are always welcome, but if you review the history of other ideas promoted by community members, you will see that there are basically two approaches:

1. "I think Arch should do <some_cool_thing>, what does everyone else think?"
2. "I've implemented <some_cool_thing> in my Arch system. Here's how I did it, if anyone else wants to try. What does everyone else think?"

No prizes for guessing which one is preferred.

In short, discussion is good; action + discussion is better.

Finally, if it's just going to be discussion, you might want to actually describe "what a real optimized init system can do for a distro", rather than simply implying that it is better than the current setup.

arvster · 2007-04-04 08:17:15

One of the reasons why I like Arch is because of its simple and therefore fast init system. Arch is the distro with the fastest boot time that I have used. I don't think any init replacement could do better than Arch does currently- I've tried initng on Gentoo; it was fast from what I recall, but certainly not better than what Arch does.

pauldonnelly · 2007-04-04 11:43:07

After running Bootchart I've concluded that the only way to speed my startup would be by reducing the time init takes before starting more processes, reducing udev's startup time, or starting some daemons after the login prompt appears. This would actually work well for me, since I have to log in and type an ssh passphrase in before I can use the system. I probably will also start X before using much of anything.

jf/ · 2007-04-04 12:09:35

tomk wrote:

Some thoughts around this topic, as like others here, I find the current system meets my needs, and I have therefore not investigated alternatives.
A discussion like this will no doubt be interesting, and user suggestions are always welcome, but if you review the history of other ideas promoted by community members, you will see that there are basically two approaches:
1. "I think Arch should do <some_cool_thing>, what does everyone else think?"
2. "I've implemented <some_cool_thing> in my Arch system. Here's how I did it, if anyone else wants to try. What does everyone else think?"
No prizes for guessing which one is preferred.
In short, discussion is good; action + discussion is better.

i've just read a dozen or so (exaggerating) posts illustrating this point already. But hey, it's not as if i didnt do any "action", did i? I did the research, and the investigation to come up with the report that i did, presenting advantages, vs disadvantages.. If i had merely wanted to be a "discusser", i would have just fired one quick one - without presenting all the stuff that i did, ask "what do u think of this", and that's it!

Finally, if it's just going to be discussion, you might want to actually describe "what a real optimized init system can do for a distro", rather than simply implying that it is better than the current setup.

it's bootup speed for me. And easy supervision of services. http://cr.yp.to/daemontools/faq/create.html#why

iphitus · 2007-04-04 12:17:47

Research is discussion.

95% of a change in initscripts would be implementation. Go create a complete, configured, customised package and implementation, then you'll realise what it involves.

None of the above implementations will help bootup speed. Look at what consumes time at boot. udev, modules, network. These cannot be hurried, and the first two cannot be backgrounded, under any system. Most other daemons start near instantaneously.

Easier supervision of services can be implemented sufficiently in our current scripts, given a little bit of effort.

James

jf/ · 2007-04-04 12:39:05

iphitus wrote:

None of the above implementations will help bootup speed. Look at what consumes time at boot. udev, modules, network. These cannot be hurried, and the first two cannot be backgrounded, under any system. Most other daemons start near instantaneously.

I would argue that modules could be. Sure, the (network) daemons might need to wait for *some* modules, but not all. Definitely not the ones involving usb, for eg...

Regarding the starting of daemons, they still have to wait for each other in the current system. This is the appropriate code portion in rc.multi...

# Start daemons
for daemon in "${DAEMONS[@]}"; do
        if [ "$daemon" = "${daemon#!}" ]; then
                if [ "$daemon" = "${daemon#@}" ]; then
                        /etc/rc.d/$daemon start
                else
                        stat_bkgd "Starting ${daemon:1}"
                        (/etc/rc.d/${daemon:1} start) &>/dev/null &
                fi
        fi
done

Sure, right now, i am running Arch on a desktop, so it doesnt really bother me much, but if i were to be looking to install Arch on a server, i would be looking for a better (or faster) way of doing things than this... Bootup time counts here in this environment.

Easier supervision of services can be implemented sufficiently in our current scripts, given a little bit of effort.

ok, so let me just play the Devil's Advocate for once. Are u merely discussing this? How do u propose we do it then?

broch · 2007-04-04 13:10:20

"Regarding the starting of daemons, they still have to wait for each other in the current system. This is the appropriate code portion in rc.multi..."
Are you talking about this server that once started never should be be stopped, or desktop/server that is booted several times a day?
Because if you are talking about server, then your arguments are pointless.

Also, before arguing upstart superiority: have you checked if there is anything to speed up (Arch BSD init)? At this point I would say that you are not a Devil's advocate, this is merely a possibility without any experimental foundation. On the same machine Ubuntu/upstart still boots slower than Arch.

There is a lot of hoopla about upstart, but I have not seen any really amazing results. On AMD 3000+/2GB RAM/7200rpm SATA Win XP boots in 12 sec to full working instantly (meaning I can instantly open FF and surf. After one year past installation, no slowdowns) GUI. If you can produce similar results with upstart, that would be something. Personally I find ubuntu quite slow. Even with upstart.

jf/ · 2007-04-04 14:11:29

broch wrote:

"Regarding the starting of daemons, they still have to wait for each other in the current system. This is the appropriate code portion in rc.multi..."
Are you talking about this server that once started never should be be stopped, or desktop/server that is booted several times a day?
Because if you are talking about server, then your arguments are pointless.

not for the environments that i work in.

Also, before arguing upstart superiority: have you checked if there is anything to speed up (Arch BSD init)?

I hope u're not starting to put words into my mouth, and assuming things of me already. I wasnt necessarily advocating upstart, and pushing for it.

At this point I would say that you are not a Devil's advocate, this is merely a possibility without any experimental foundation. On the same machine Ubuntu/upstart still boots slower than Arch.

ok, or if not, let's just call it "giving the medicine back". Not all discussions are bad; sometimes discussions have to be made first before "action" can take place.

As for ubuntu bootup speed, i'm not going to defend it, but are u sure u did look into the services that u started up with Ubuntu, and made sure that they were the same? I'm sure Ubuntu by default must start up more processes than Arch....

There is a lot of hoopla about upstart, but I have not seen any really amazing results. On AMD 3000+/2GB RAM/7200rpm SATA Win XP boots in 12 sec to full working instantly (meaning I can instantly open FF and surf. After one year past installation, no slowdowns) GUI. If you can produce similar results with upstart, that would be something. Personally I find ubuntu quite slow. Even with upstart.

broch · 2007-04-04 14:55:10

"not for the environments that i work in."
either way, you start services several times a day which hardly makes it server (assuming server services) or not.

"I hope u're not starting to put words into my mouth, and assuming things of me already. I wasnt necessarily advocating upstart, and pushing for it."
No, what I am asking is whether you check if upstart will bring more speed to Arch? If so, then great

"As for ubuntu bootup speed, i'm not going to defend it, but are u sure u did look into the services that u started up with Ubuntu, and made sure that they were the same? I'm sure Ubuntu by default must start up more processes than Arch...."

shrug,
of course I killed what is possible to kill, same as with Arch or suse or slack.
I am comparing systems that I optimized to best of my knowledge. Is this enough? I don't know but I assume that we are not talking about re-compiling whole system?

Romashka · 2007-04-04 15:40:01

I don't see any serious reason to change Arch's init system which is one of the best I've ever seen with any of init-replacements. There are more than upstart and runit (no need to list all of them here), but they don't worth to replace Arch's init system. I don't even say they violate the philosophy of of Arch Linux - this is obvious.

Cerebral · 2007-04-04 17:54:05

jf/ wrote:

I would argue that modules could be. Sure, the (network) daemons might need to wait for *some* modules, but not all. Definitely not the ones involving usb, for eg...

Just a point of note, making assumptions about people's hardware is a bad idea.
I have a USB wireless network dongle that I use to connect to my network. My daemons would have to definitely wait for the ones involving usb.

shining · 2007-04-04 18:30:47

I love the simplicity and performance of arch init system (from an user pov), it's one of the thing I like the most about arch
Though, the good speed compared to other distribs is probably that's the init scripts are less bloated, and much less services started by default. I tried to disable every services I didn't need in debian or ubuntu, but it seems there were still a lot left and they still booted slower than arch.
I wonder if another init system could be much faster than arch one, or if arch one could be optimized, or would need to be replaced in order to get a noticeable boost.
But overall, the current system is very good imo, so I don't see any reasons for replacing it.

baze · 2007-04-04 19:19:37

i think upstart is the way to go, since it handles events that might happen during the boot process and i think it's a nice modern system for modern systems
maybe not yet perfect, but it might become a good solution once it also replaces cron for example. i would vote for upstart. the current bsd style init scripts are good, because they are fast and it's easy to configure them, but they are not capable of changing dynamically according to the environment of the system. for example when you have the adsl daemon trying to start your connection, but you aren't connected to any network. in such a case, adsl should be started automatically, when your computer is connected via wlan, ethernet or whatever connection. upstart handles such things.
of course it's possible to background the daemon, so it doesn't slow down the boot process while trying to connect, but it will fail and when you connect to a network, it will not automatically try to connect via pppoe again. you have to do this manually, and i think such cases could be handled better and upstart was designed to do that.

emphire · 2007-04-04 21:39:27

There's also init-ng. It might be a little more similar to the init system of arch.
I think it's a great idea to use it such an init system.

To be honest, I think such a system is actually more simple than the current one. In the current system, you have to figure out what order to list your daemons in rc.conf and which ones you can and can't start in the background as a result.

On the other hand, with the parallel init systems, you should be able to add them in any order and the developer/maintainer will already have a list of daemons that are required to load before their daemon and the init system will take care of it all... that's more simple (and faster) if you ask me.

iphitus · 2007-04-04 21:41:14

RE Modules:
You can speed these up if you want, turn off autoload, and then have them loaded at at time you think is more comfortable for you.

As for the daemons, just in case you didnt realise, there's a background option, so you can background network and other daemons that you think take too long.

Rather than discussing, write some patches and code, and we can discuss those. If you want somethng implemented, in Arch, generally it's better to go ahead and do it first.

James

Last edited by iphitus (2007-04-04 21:43:39)

Roberth · 2007-04-04 21:55:28

This suggestion violates the whole "keep it simple" guideline, which arch follows, so I doubt it even will be considered...

emphire · 2007-04-04 22:43:45

iphitus wrote:

RE Modules:
As for the daemons, just in case you didnt realise, there's a background option, so you can background network and other daemons that you think take too long.

I think backgrounding the network daemon is a bad idea (unless you don't have any daemons that require network access). For me that's the whole point of these kinds of init replacements. They'll keep track of dependencies for you and start everything in the background as soon as possible.

If ask me, being able to just list your daemons in any order and have them work (and load in the proper order as quickly as possible) without having to look-up what each damon might possibly require (and keep track of changes in those requirements with new versions) follows KISS a lot more than having to deal with it all to order your daemons list (and lossing the option to background daemons that are required for other ones).

liem · 2007-04-04 23:37:10

What the heck? I didn't know KISS meant make it "easy" for the user. I thought it meant don't do fancy tricks like "dynamic init" or abstract away the user from the workings of the computer. Especially for some seconds lost on booting.

Sure BSD init has some problem, laptops with different network configurations comes to mind, but its simplicity makes it easy for me, as a user, to modify them to fit my needs.

What is the problem people? My system spends more time in pre-grub + grub then Arch linux does booting. Daemons start in about 1 second. I don't see how complexity gonna improve on that.

Don't say it modern, it doesn't prove or add anything.

deficite · 2007-04-05 02:48:05

I don't see how complexity gonna improve on that.

It won't. In fact it'll actually make it slower, more than likely. People refuse to understand this.

If ask me, being able to just list your daemons in any order and have them work (and load in the proper order as quickly as possible) without having to look-up what each damon might possibly require (and keep track of changes in those requirements with new versions) follows KISS a lot more than having to deal with it all to order your daemons list (and lossing the option to background daemons that are required for other ones).

Perhaps you don't understand the shade of meaning that Arch uses when it says "Simple". Simple does NOT mean that something is "easy", it means it isn't complicated and over-complex. Ever heard of DOS's autoexec.bat? It was a stinkin' batch file and it ran everything you typed into it in the order you typed into it. The reason why I mention this is not because I want to adopt DOS's init system, but instead because I wanted to show you the pinnacle of simplicity. Was it easy to use? Most of the time. But DOS also had issues of TSR's and services, etc. that depend on other services. I'd like for you to point out a simpler system than autoexec.bat that is actually in mainstream use. See? Simple does NOT equal easy.

However, I'd like to mention what my Jr. High principal always told us: "Anything is easy if you know how to do it." I actually find Arch's init system to be the EASIEST system out there. I know EXACTLY what it is doing at all times. I tried to grok Ubuntu's system and I found myself having to read a bunch of stuff from different sources to make sense of it. Is that easy? No. Not for me. Simple IS easy if you throw out your Windows conditioning that everything should be done for you and that you can't think for yourself. You say we should be able to make a list of services and they should all start in the order Arch thinks they should. I on the other hand say that if I want x to start before y, then x BETTER start before y. You see, I'M the user. I'm not just there to share the experience. My computer is a tool and I want it to do exactly what I say.

Hell, I bet you spent more time writing this post than a new init system will save you in your lifetime. The Linux kernel takes longer to start on my machine than anything else (and I'm connected via WiFi on a buggy and slow as hell driver and through DHCP on top of that). I already said one thing that may give you a little boost, which is caching (which may actually slow you down due to overhead). You can also try suspending to disk (aka hibernating) instead of just shutting down.

What do u guys think of replacing and moving from the current BSD-init style (it's great, but there's more stuff out there!!!) to a better, "totally optimized", "rad" (excuse the slang, also known as "awesome") init system?

Explain to me everything you know about the BSD init style. I'm curious.

Last edited by deficite (2007-04-05 02:51:51)

emphire · 2007-04-05 04:34:11

deficite wrote:

Perhaps you don't understand the shade of meaning that Arch uses when it says "Simple". Simple does NOT mean that something is "easy", it means it isn't complicated and over-complex. Ever heard of DOS's autoexec.bat? It was a stinkin' batch file and it ran everything you typed into it in the order you typed into it. The reason why I mention this is not because I want to adopt DOS's init system, but instead because I wanted to show you the pinnacle of simplicity. Was it easy to use? Most of the time. But DOS also had issues of TSR's and services, etc. that depend on other services. I'd like for you to point out a simpler system than autoexec.bat that is actually in mainstream use. See? Simple does NOT equal easy.
However, I'd like to mention what my Jr. High principal always told us: "Anything is easy if you know how to do it." I actually find Arch's init system to be the EASIEST system out there. I know EXACTLY what it is doing at all times. I tried to grok Ubuntu's system and I found myself having to read a bunch of stuff from different sources to make sense of it. Is that easy? No. Not for me. Simple IS easy if you throw out your Windows conditioning that everything should be done for you and that you can't think for yourself. You say we should be able to make a list of services and they should all start in the order Arch thinks they should. I on the other hand say that if I want x to start before y, then x BETTER start before y. You see, I'M the user. I'm not just there to share the experience. My computer is a tool and I want it to do exactly what I say.

I'm sure it would be easier for package maintainers if they didn't have to list package dependencies for pacman too.

I agree with some of your points. I think the computer should do exactly what I say (although, I think sane and usable defaults are a wonderful complement to control and configuration). The thing that frustrates me (a little bit) about the current init system is that it doesn't give me as much control as I want. In the current system, you put an '&' in front of one of your daemons and there's no telling what other daemons will load before it's done loading.

Last edited by emphire (2007-04-05 04:57:29)

Arch Linux

#1 2007-04-03 22:51:58

RFC: a new init system for Arch

#2 2007-04-03 23:03:15

Re: RFC: a new init system for Arch

#3 2007-04-03 23:07:46

Re: RFC: a new init system for Arch

#4 2007-04-04 04:12:01

Re: RFC: a new init system for Arch

#5 2007-04-04 07:49:47

Re: RFC: a new init system for Arch

#6 2007-04-04 08:15:49

Re: RFC: a new init system for Arch

#7 2007-04-04 08:17:15

Re: RFC: a new init system for Arch

#8 2007-04-04 11:43:07

Re: RFC: a new init system for Arch

#9 2007-04-04 12:09:35

Re: RFC: a new init system for Arch

#10 2007-04-04 12:17:47

Re: RFC: a new init system for Arch

#11 2007-04-04 12:39:05

Re: RFC: a new init system for Arch

#12 2007-04-04 13:10:20

Re: RFC: a new init system for Arch

#13 2007-04-04 14:11:29

Re: RFC: a new init system for Arch

#14 2007-04-04 14:55:10

Re: RFC: a new init system for Arch

#15 2007-04-04 15:40:01

Re: RFC: a new init system for Arch

#16 2007-04-04 17:54:05

Re: RFC: a new init system for Arch

#17 2007-04-04 18:30:47

Re: RFC: a new init system for Arch

#18 2007-04-04 19:19:37

Re: RFC: a new init system for Arch

#19 2007-04-04 21:39:27

Re: RFC: a new init system for Arch

#20 2007-04-04 21:41:14

Re: RFC: a new init system for Arch

#21 2007-04-04 21:55:28

Re: RFC: a new init system for Arch

#22 2007-04-04 22:43:45

Re: RFC: a new init system for Arch

#23 2007-04-04 23:37:10

Re: RFC: a new init system for Arch

#24 2007-04-05 02:48:05

Re: RFC: a new init system for Arch

#25 2007-04-05 04:34:11

Re: RFC: a new init system for Arch

Board footer