Now this was a real wild swing. I was reading the old article about running startup services in parallel with make, but to be honest I wasn’t really sold on the idea.

For one thing, I’m still not confident the services I want are all that numerous, and additionally the article doesn’t seem timely now. I’ve looked through the sample configuration files and I think I get the gist, but I don’t care to try it. For some reason it just doesn’t enthuse me.

But there is this rather tantalizing footnote:

It is possible that a more aggressive approach could be taken by modifying the “action field” in the /etc/inittab file to be “once” rather than “wait”. This could allow the user to log in even before the services have finished executing. However, this is beyond the scope of this article. View man inittab for further details, and remember, UML is your friend.

You mean if I change the entries marked “wait” to “once” in my inittab file, I’ll get the same effect … or at least a “more aggressive approach” to the idea? Hey — and if I trigger an autologin process, I could have X up and running while services are still getting warmed up. …

Heck, I’ll try anything once. So I did. The relevant parts of the Arch inittab, which I hadn’t messed with before then, looks like this now.

rs:S1:once:/etc/rc.single
rm:2345:once:/etc/rc.multi
rh:06:once:/etc/rc.shutdown
su:S:once:/sbin/sulogin -p

Anywhere you see ‘once,’ it used to say ‘wait.’ As I understand it, ‘wait’ makes it delay while it begins, while ‘once’ triggers it and moves on. My depth of the ideas here is a bit shallow, I admit.

I’m still investigating the processes there, and I feel a bit noobish just tickling things to get the results I want, but it hasn’t killed my system, and I’m starting up faster. That’s what I’m after.

Besides, even in a worst-case scenario, a rebuild is only 15 minutes away.