[request] upstart

baze · 2007-02-07 21:35:56

I asked in #upstart and they said upstart would be ready to work on any distro now and since i like the whole idea with the event based init system, i'd like to see it in arch, but the initscript part is a bit too hard for me, so maybe someone can take this on..

i'd really like to have upstart as the default init system in arch eventually, and i hope that i'm not the only one

mucknert · 2007-02-07 21:40:17

Although that this question might start a flamewar of nuclear size I must ask: why? What's wrong with the BSD-style init-system? It perfectly fits into Archs KISS-Philosophy. Does upstart too? Why fix something that isn't broken?

Mikko777 · 2007-02-07 21:52:56

What does init systems actually do?

mucknert · 2007-02-07 22:18:42

http://en.wikipedia.org/wiki/Init
Here you go. I am lazy today.

STiAT · 2007-02-08 08:05:08

Hmh, i must say init is one of the things i really do love in arch.

I always prefered bsd over linux, easy with portage, easy init, just a bit a hassle of porting apps.

Arch has all, easy init, super package managing, and is a linux system, makes doing packages easier without the need of always patching code.

Mikko777 · 2007-02-08 08:36:26

mucknert wrote:

http://en.wikipedia.org/wiki/Init
Here you go. I am lazy today.

OT: wikipedia is just awesome nowadays, in the past you said google it now its wikipedia

baze · 2007-02-08 09:20:16

well, the point of upstart is that it's event based and reflects what happens or might happen in modern systems, what the old init systems just didn't. it's _much_ more flexible and imho it's the way to go.

noriko · 2007-02-08 09:35:49

@baze

can you actually provide any info to backup- your ideas/claims ..
if it come to a vote or something about whether there was any point trying to make it work with arch, or providing an official pkg then I'd be interested in voting| NO. because, i know nothing about it; and am not willing to go research.

you've so far made no real important points on why it would be a viable option in arch.
all you've done is state a few features of it, with no reason why it's better (or worse) than the current system.
=============================
btw more info on Upstart can be found over @ http://www.netsplit.com/blog/articles/2 … n-universe

rant, over.

Last edited by noriko (2007-02-08 09:36:03)

wizzomafizzo · 2007-02-08 10:05:19

Sorry noriko but that's the most retarded rant I've ever heard in my life. You contradicted yourself and "so far made no real important points".
If baze wants upstart in Arch, go him. If baze wants someone else to put upstart in Arch, good luck with that. Linux is about doing whatever the hell you feel like with your system, it's not as if he was forcing you to use upstart yourself.

baze · 2007-02-08 10:05:39

well, i figured people would know a bit about things before they say "no" to something, but it seems i was wrong..
there have been talks about upstart in this forum too, the forum search is not that difficult

anyway, here are just some infos about upstart:
http://bbs.archlinux.org/viewtopic.php?id=24487
https://wiki.ubuntu.com/ReplacementInit
http://upstart.ubuntu.com/ (i can already hear people crying about the fact that it's developed by ubuntu guys -_-)
and if you don't want to read, here's a video presentation from linux.conf.au: http://mirror.linux.org.au/linux.conf.a … ay/102.ogg

the short version of all this: upstart is even based, that means it launches the required stuff automatically and not due to some predefined settings, which is just an outdated way from the time when the computer setup wasn't changing and much more simple than it is today.
for example when you want to start an apache daemon, it makes absolutely no sense to start it, when there is no network available. upstart is capable of detecting if there is a network running, and then starts apache, if the user configured it. this does not only mean the boot process, but the whole time the system is up. upstart does even more: when the network is not available anymore (shut down for example or there has been an error with the connection), it automatically stops the daemon and restarts it when the network is back.

imagine another case: someone has his /home on an usb stick but hasn't plugged it in when he was booting. with upstart, it will automatically be used when you found the stick and plug it in. there are lots of use cases where stuff has to be running only in certain situations. like starting cups doesn't make sense when there is no printer attached. when you plug the printer in, upstart automatically starts the cups daemon and stops it when the printer is gone again.
such situations occur much more often than let's say 10 years ago and upstart reflects those changes.

btw, i started working on a PKGBUILD for upstart before opening this request, but atm it only contains the daemon and nothing special. just the configure line from the upstart website. the whole part of the rules is not done yet, because i'm not that into that part, but i'll keep on trying to get that part running of course. but since there is nothing special in the PKGBUILD yet, i did not see a reason why i should post it here.. well, anyway:

pkgname=upstart
pkgver=0.3.2
pkgrel=1
pkgdesc="Upstart is an event-based init daemon"
depends=('glibc')
makedepends=()
url="http://upstart.ubuntu.com"
source=(http://upstart.ubuntu.com/download/$pkgname-$pkgver.tar.bz2)

build() {
  cd ${startdir}/src/$pkgname-$pkgver

  ./configure --prefix=/opt/upstart --sysconfdir=/etc --enable-compat=sysv
  make || return 1
  make DESTDIR=${startdir}/pkg install
}

Last edited by baze (2007-02-08 10:10:03)

iphitus · 2007-02-08 10:26:45

Event based and all is great and wonderful, makes awesome marketing material. But who is to say that the init system is the best location for this. init starts and shuts down my computer. I don't want it to do any more than that. I'd rather a seperate daemon that starts after boot. It'd be nice if upstart started as that. In the examples you provide, there's no requirement that the executor be part of the init system.

Take for example your mounting home example. It's not as simple, if someone's already logged in on that user, then mounting the home would cause problems as there's already files being used there. There's also no need on the mounter being part of the initscripts.

And automounting? That's already done by piles of things. ivman for example can do it conditionally on any hardware state.

ivman could also handle your printer example. ivman is a generic hal hardware event handler - that happens to do automounting.

I don't think upstart's approach is the best way. It'd be far better as a seperate program with it's dedicated task, not linked into the initscripts. Though, that's probably because i love arch's dead simple bash initscripts.

I agree with wizzomafizzo though, you're still free and encouraged to go and package it, though you should realise that just because "it's event based" doesnt mean it's the ideal solution.

James.

baze · 2007-02-08 10:35:24

yep, it might not be the ideal solution, but it's definately a more flexible one compared to the current situation.

ekerazha · 2007-02-27 17:47:46

Wow... this is my first message

mucknert wrote:

Although that this question might start a flamewar of nuclear size I must ask: why? What's wrong with the BSD-style init-system? It perfectly fits into Archs KISS-Philosophy. Does upstart too? Why fix something that isn't broken?

Sometimes it's a broken thing to fix, other times it's a thing to improve. Did Arch Linux 0.1 works? Yeah. Is Arch Linux 0.8 improved from 0.1? I think so.

Is "upstart" an improvement? Take a look at this: http://www.netsplit.com/blog/articles/2 … n-universe

From that page:

We've been able to hack the existing system to make much of this possible, however the result is chock-full of race conditions and bugs. It was time to design a new system that can cope with all of these things without any problems.
What we needed was an init system that could dynamically order the start up sequence based on the configuration and hardware found as it went along.

iphitus wrote:

Event based and all is great and wonderful, makes awesome marketing material. But who is to say that the init system is the best location for this. init starts and shuts down my computer. I don't want it to do any more than that. I'd rather a seperate daemon that starts after boot. It'd be nice if upstart started as that. In the examples you provide, there's no requirement that the executor be part of the init system.

Imho the point is: why should you "start" anything? To make it "run". The "starting" concept hasn't a great value by itself, it is finalized to "run" something. So imho the final scope is not "start something" but "run something". This is why I think the "upstart" approach is a powerful and flexible one.

Just my 2 cents.

P.S.
Excuse me for my poor English but it isn't my native language

Last edited by ekerazha (2007-02-27 17:49:55)

mildred · 2007-04-18 16:44:44

I too would like to see upstart integrated in Archlinux.
Why ? It is true that the current init system is very fast and very good. My goal is not to boot faster because this would not be easy to do better than now. What I would like is a way to start and stop services dynamicly. Actually my computer is a laptop and I don't want to have services running if i don't need them (in order to save power energy). If upstart was installed, services and applications could automacilly be started/stoped depending of the network connectivity. It could be easy to start/stop services and applications when the computer is going to sleep.
But maybe upstart is not yet capable of such things. I think I will try to install it to see how it works.

beza1e1 · 2007-04-18 21:51:23

mildred, you could write udev rules, which start/stop your services or is there a permission problem with that?

mildred · 2007-04-19 09:28:32

Of course i can write udev rules, of course I can modify the sleep scripts to execute commands i want to be executed ... And i have to reproduce the same shell script multiple times, one for the sleep scripts, one other for udev, and for networkmanager and for the standard init. i would rather prefer everything in the same place.

Something else, i don't like to configure my system. If I choose ArchLinux it was i think for pacman which is a very simple and flexible package manager. I also prefer the BDS init system used in Arch to the standard runlevel system that forces you to maintain many symlinks.
To achieve what I want with the current system, i have to think of what i need, when and where to specify it (as i said, there are many places. And sometimes these places don't even exists and you must modify programs to create them). And you have to do it again anytime you install the distribution.

Rulatir · 2008-02-11 00:27:58

My (use) case for Upstart: I am a hobbyist musician and I work a lot with software synthesizers like Timidity++ or fluidsynth. I have this dream of having software synthesis JustAvailable(TM) on my system, so I can just boot the machine, start RoseGarden and compose. I even pondered writing a daemon to manage all this - start jackd, start timidity, start MIDI loopback, connect everything, then monitor and restart if anything stopped working. Now what I have seen of Upstart, I believe it could be THE tool to implement this functionality.

Last edited by Rulatir (2008-02-11 00:31:55)

Misfit138 · 2008-02-11 02:27:27

Just a friendly reminder that this thread is nearly a year old...So before anyone goes on a rant, just be conscious of that.

cactus · 2008-02-11 02:34:35

O' misfit138.
Thou hath saved me.

Misfit138 · 2008-02-11 03:16:53

cactus wrote:

O' misfit138.
Thou hath saved me.

I saved you...the last taco! Microwave it for 30 seconds..it's yours.

cactus · 2008-02-11 08:37:03

wewt!

erm67 · 2008-02-11 22:42:16

Rulatir wrote:

My (use) case for Upstart: I am a hobbyist musician and I work a lot with software synthesizers like Timidity++ or fluidsynth. I have this dream of having software synthesis JustAvailable(TM) on my system, so I can just boot the machine, start RoseGarden and compose. I even pondered writing a daemon to manage all this - start jackd, start timidity, start MIDI loopback, connect everything, then monitor and restart if anything stopped working. Now what I have seen of Upstart, I believe it could be THE tool to implement this functionality.

What functionality of upstart is needed for what you have in mind that cannot be provided by existing tools?

I mean to replace all Archlinux init functionalities with upstart at least all /etc/rc.* should be rewritten, new ones to replace inittab written and probably who knows how many /etc/rc.d/* tested and maybe fixed if they have problems with upstart. All those new scripts should be than maintained and kept in sync with the official Archlinux scripts, it is a lot of work.
I personally like the idea of testing upstart but that is too much work, and I am not sure things will improve much after that.

debackerl · 2008-02-20 20:53:12

I agree that replacing the current init scripts with upstart would be a lot of work. But I would like to know what are the alternative to monitor daemons (i.e. when my web server dies, how can it be restarted automatically)? I think that such a feature is really important for servers. Finally, wouln't it be possible to ask upstart to run our existing init scripts, and progressively migrate to upstart?

PJ · 2008-02-20 22:38:54

debackerl wrote:

But I would like to know what are the alternative to monitor daemons (i.e. when my web server dies, how can it be restarted automatically)? I think that such a feature is really important for servers.

If your web server (or any other daemon) dies it want be that easy to find out whether or not it is still working. In most cases it will leave some traces that will indicate that the server is still running even if it has crashed. That means that this use case will not be as effective as one could hope.

debackerl wrote:

Finally, wouln't it be possible to ask upstart to run our existing init scripts, and progressively migrate to upstart?

Sure, it is possible. I did something like this for InitNG when it was hyped. I am pretty sure that Ubuntu has something similar for the SYSV compability.

I think the concept is interesting but I don't think it will do a better job compared to the current init-script. I wasn't that impressed of how upstart worked on Kubuntu.

damjan · 2008-07-17 15:35:33

Has anyone tried to run Upstart in Arch? Upstart is backward compatible so actually Arch init scripts should all work.
And then for other things one can gradually replace rc.d scripts with upstart ones.

Arch Linux

#1 2007-02-07 21:35:56

[request] upstart

#2 2007-02-07 21:40:17

Re: [request] upstart

#3 2007-02-07 21:52:56

Re: [request] upstart

#4 2007-02-07 22:18:42

Re: [request] upstart

#5 2007-02-08 08:05:08

Re: [request] upstart

#6 2007-02-08 08:36:26

Re: [request] upstart

#7 2007-02-08 09:20:16

Re: [request] upstart

#8 2007-02-08 09:35:49

Re: [request] upstart

#9 2007-02-08 10:05:19

Re: [request] upstart

#10 2007-02-08 10:05:39

Re: [request] upstart

#11 2007-02-08 10:26:45

Re: [request] upstart

#12 2007-02-08 10:35:24

Re: [request] upstart

#13 2007-02-27 17:47:46

Re: [request] upstart

#14 2007-04-18 16:44:44

Re: [request] upstart

#15 2007-04-18 21:51:23

Re: [request] upstart

#16 2007-04-19 09:28:32

Re: [request] upstart

#17 2008-02-11 00:27:58

Re: [request] upstart

#18 2008-02-11 02:27:27

Re: [request] upstart

#19 2008-02-11 02:34:35

Re: [request] upstart

#20 2008-02-11 03:16:53

Re: [request] upstart

#21 2008-02-11 08:37:03

Re: [request] upstart

#22 2008-02-11 22:42:16

Re: [request] upstart

#23 2008-02-20 20:53:12

Re: [request] upstart

#24 2008-02-20 22:38:54

Re: [request] upstart

#25 2008-07-17 15:35:33

Re: [request] upstart

Board footer