I have been using F9 for awhile now, I am pretty happy with it so far.
Since the release of F9, I lost my laptop and had to install it again to a 3 years+ old laptop, X31.
But it is working great, I don’t have that much to complain about.
Yesterday, a colleague of mine asked a question about “UPSTART”.
There was an article on “Linux Format” with a small example.
Shamefully enough, I didn’t know that init has been replaced with the upstart.
For my own benefit, I have started to look up what it is, and how it is going to affect Fedora/RHEL future releases.
This is quite interesting because, it has been my jobs and interests to write SysV scripts for custom application to do “start/stop/status”. Also, I haven’t seen anything relating the upstart with “service” minds in RHEL and Fedora.
Because of that, how it is going to be integrated in F10 would be very interesting.
[LWN.Net] LPC: Upstart 1.0 plans: manifesto for a new init
Let’s make two things clear about Upstart, a proposed replacement for the Linux “init” process. First, it’s not there to speed up boot, and second, it’s not intended to parallelize startup. “Upstart is not for what most people think it is for,” said its author, Scott James Remnant, in a talk in the dbus miniconference at the Linux Plumbers Conference. What it is there for is to expand the capabilities of “init” on Linux, replace some scripts and workarounds with rules that are intended to be easier to understand and modify, and enable future improvements. Remnant is a Canonical employee, and Upstart is in Fedora as of version 9, making it a welcome example of a Canonical-sponsored project finding its way into other distributions.
While Greg Kroah-Hartman mentioned a list of core software on the Linux platform in his Plumbers Conference talk, “the one thing he never put in there was init,” Remnant said. The Linux init, originally by Miquel van Smoorenburg, has been unchanged for years, and is modeled on the System V Unix init, which is even older. Instead of updating it, Remnant says that, for too long, distributions have just worked around it. The startup process has traditionally consisted of shell scripts, started by init, but containing workarounds and extensions accumulated over the years. For example, Debian has a wrapper program called start-stop-daemon, that manages PID files, to keep track of what process ID a daemon process ends up with. Upstart handles that itself.
Current features of upstart include sending notifications for system events, for example, when a service starts; eliminating race conditions, by offering dependency tracking; and removing some service startups from the critical path for boot, again by handling dependencies. Upstart allows a distribution or sysadmin to spell out the critical path in a script, and also specify dependencies. Tracking dependencies allows distributions to eliminate “sleep” loops from the boot sequence, and instead take actions based on events.
Events are not limited to the runlevel changes familiar to sysvinit users, but can depend on other things on the system. But what other things? Future directions for Upstart could be ambitious. For 1.0, Remnant is considering adding the ability to do tasks based on cron-like criteria such as “hourly.” But should upstart really replace cron? Another possibly useful direction would be an “idle” event. The Common Unix Printing System (CUPS) is a service that makes sense to start “30 seconds before the user thinks of clicking on the print button,” he said. CUPS is not in the critical path for boot, but needs to be running to detect printers before the user needs them. Should it be possible to start non-critical services when the system becomes idle?
Even though fast boot isn’t the goal of upstart, Remnant is optimistic about being able to help. Some of the slow booting problems that Arjan van de Ven and Auke Kok identified at the conference are deep in the weeds of nested scripts, and might be smoked out by a simpler init layout. “To make boot fast we have to do a bunch of different stuff. it makes it easy for us to do the real work,” Remnant said.
[Fedora-devel-list] upstart plans for F10+
- From: Bill Nottingham <notting redhat com>
- To: fedora-devel-list redhat com
- Subject: upstart plans for F10+
- Date: Thu, 22 May 2008 16:04:45 -0400
Since I've been asked in various places what we're planning to
do with upstart now that Fedora 9 has shipped, I figured I'd
lay out the basic plan.
To do any large-scale conversion of SysV init scripts to upstart,
we need some features that are not in the current (0.3.9) version.
Hence, the first thing is to get upstart 0.5 ready for inclusion.
For example, we need support for the following:
- Depending on multiple events
I.e., have something start only if two separate events have
both completed successfully. For a disturbing example of how
we work around this now, read /etc/event.d/serial.
- Ability to enable/disable events in a way other than removing
the file
(The reasoning for this should be fairly obvious)
- Ability to group events into sets, or profiles
This allows us to handle the sort of behaviors that runlevels are
used for sanely.
- Ability to easily have upstart events depend on SysV scripts, and
vice-versa
If one of a SysV scripts' dependencies is started by upstart, we
need to be able to still handle that sanely.
This isn't meant to be an exhaustive list, but it is meant to
illustrate why we can't just move services right now.
Once we get upstart 0.5 in, we can then look at potentially moving
some subset of things that are now handled elsewhere to upstart.
Examples would be:
- Always-on services such as dbus, syslog, and audit
- Reworking things like netfs to be more sane, when
it comes to networks coming and going, network block devices being
attached and detached, and so on
- Potentially splitting some of rc.sysinit into multiple events.
Not sure this buys us much, as right now the flow is *extremely*
sequential (start_udev -> fsck -> remount r/w -> clean out /tmp)
- Coming up with a sane network notification strategy
Right now, we have events kicked off on network changes:
- via netreport
- via NetworkManagerDispatcher
- conceivably, via upstart (after all, spawning commands/etc based
on events is its raison d'etre)
Having a coherent strategy for apps to only need to worry about
dropping things in one place would make sense.
- (possibly) having either upstart 'handle' sysv services more natively
or wrap tools such as chkconfig, /sbin/service so they handle both
SysV and upstart.
All clear as mud?
Bill
