Ubuntu's Success Story: the Upstart Startup Manager (LinuxPlanet)

Posted Apr 9, 2010 10:36 UTC (Fri) by kreijack (guest, #43513)
Parent article: Ubuntu's Success Story: the Upstart Startup Manager (LinuxPlanet)

I discovered that with upstart it not possible to switch a job to "manual mode". Even though a job is stopped via the command

# stop <jobname>

in the next reboot the it will be restarted.

It is possible to move the init/<jobname>.conf file to another location in order to avoid the "automatic" behavior. But so it is not possible to start it manually via the "start" and "stop" command.

To me it seems a big regression to the old SysV init script. I am alone to think that ?

Moreover the last time that I tried it, I discovered that my ubuntu 10.4 (bat is a beta) when booted in single mode, mysql was running !

Ubuntu's Success Story: the Upstart Startup Manager (LinuxPlanet)

Posted Apr 9, 2010 11:03 UTC (Fri) by stumbles (guest, #8796) [Link]

I've not used upstart but if it behaves as you say, I would call that a regression or at least unacceptable.

Ubuntu's Success Story: the Upstart Startup Manager (LinuxPlanet)

Posted Apr 9, 2010 11:58 UTC (Fri) by marcH (subscriber, #57642) [Link]

A different problem I often face is when I start/kill frequently a service under development in order to test it. At some point upstart will flag it as unstable and refuse to start it. My current workaround (shame) is to reboot the machine.

Maybe upstart should consider that a command run from a tty is always right?

Ubuntu's Success Story: the Upstart Startup Manager (LinuxPlanet)

Posted Apr 9, 2010 14:03 UTC (Fri) by mdz@debian.org (guest, #14112) [Link] (6 responses)

I discovered that with sysvinit it not possible to switch a job to "manual mode". Even though a job is stopped via the command

# /etc/init.d/jobname; stop

in the next reboot the it will be restarted.

It is possible to move the /etc/rc?.d/S??jobname file to another location in order to avoid the "automatic" behavior...

Seriously, though...this is easy to do with upstart. The /etc/init/jobname.conf file describes precisely which events will cause the job to be started and stopped. If you don't specify any such events (i.e. comment out the "start on" and "stop on" lines), then it won't be started automatically.

So by commenting out these lines, you get the behavior you want: it won't start at boot time, but "start jobname" and "stop jobname" will still work.

Ubuntu's Success Story: the Upstart Startup Manager (LinuxPlanet)

Posted Apr 9, 2010 14:25 UTC (Fri) by kreijack (guest, #43513) [Link] (5 responses)

Of course by hand everything is possible. But what happens if you update the package ? The system asked you to decide which scripts (the old one with your configuration, and the new one with the default configuration) have to maintain..

With the sysV soft-link approach, the package-manager is able to update the script leaving the start/stop configuration untouched. With upstart this is a step backward.

A tool which want to manage the services, has to modify a file... From a packager POV this is a mess.

I don't want to say that upstart is fully wrong, but there are some "design issue" which have to be resolved. To me the point is that upstart is too young to be used in a LTS (long term support) distribution.

Debian (for example) still use the old sysv approach (at the time an hybrid: upstart + sysv links); the same is true for Ubuntu 9.10

Ubuntu's Success Story: the Upstart Startup Manager (LinuxPlanet)

Posted Apr 9, 2010 15:24 UTC (Fri) by mdz@debian.org (guest, #14112) [Link]

It doesn't really matter whether symlinks or files are used; your point is that the start/stop configuration is separate from the script. You're right that upstart doesn't have that separation at present, and both are stored in the job configuration file. This does complicate the creation of tools to manage services.

However, upstart's method is quite sufficient for the scenario which was described above, i.e. switching a job to "manual mode". These files virtually never change in post-release updates, so this is a minor consideration.

In response to your final point, Ubuntu 10.04 LTS still uses a "hybrid" arrangement, just as 9.10 did, though a few more jobs have been migrated to upstart.

Ubuntu's Success Story: the Upstart Startup Manager (LinuxPlanet)

Posted Apr 9, 2010 17:06 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (3 responses)

Has anyone seen an analysis of boot times which goes into detail about how much boot time savings native upstart jobs are actually providing?

If the general purpose distros are all still running upstart in hybrid mode, it makes it difficult for me to get a clear picture of what upstart's boot time savings actually are compared to pure SysV init.

I understand that theoretically the parallel service start up its capable of should reduce boot times. But I haven't seen an analysis which measures that specifically. I'd love a reference if someone has one.

-jef

Ubuntu's Success Story: the Upstart Startup Manager (LinuxPlanet)

Posted Apr 10, 2010 5:35 UTC (Sat) by rilder (guest, #59804) [Link] (2 responses)

There is nothing new(or better) in parallel service startup of upstart. SysV can be(and has been) modified for parallel startup of services.
I have used bootchart before to obtain the booting phase timings.

What Upstart is not

Posted Apr 11, 2010 12:04 UTC (Sun) by sladen (guest, #27402) [Link] (1 responses)

Upstart is not about speed, it is about enabling a distro to boot on modern dynamic hardware setups (eg. the system needs to wait for the correct USB hard disk with the root filesystem to be inserted, rather than just dying).

...and what is "new" is that Upstart is not dependency-based, it is the opposite. You start from nothing, and see where you end up; there is no presumption that you'll end up with a functioning system but Upstart will launch what it can based on the combination of presently available of hardware, functioning network connection(s), and the configured state of system software—all of which may change over time.

What Upstart is not

Posted Apr 17, 2010 8:27 UTC (Sat) by liljencrantz (guest, #28458) [Link]

True, but upstart _should_ be about speed. Not exclusively of course, but seeing how most Linux kernels are running on ARM and other tiny embedded hardware, and even Ubuntu, the main user of upstart, is quickly moving towards netbooks and smartphones, it should be completely obvious that boot speed _is_ one of the critical aspects of initialization that needs to be handled.

Ubuntu's Success Story: the Upstart Startup Manager (LinuxPlanet)

Posted Apr 9, 2010 15:10 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

That stops the job at hand, doesn't disable it... It boils down to what is more reasonable to do on next boot with a job that was stopped on shudown:

Each boot should offer the same configuration, set permanently in some way. That a particular job was or not running on shutdown is inconsecuential.
A reboot is simply a temporary service interruption, it makes sense to keep stopped jobs stopped, and so on.

The first above is easier to handle, and has the benefit that a reboot gets you into a known good state (so a reboot is useful to unwedge a machine, also in case it got its jobs messed up in some unknown way).