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
Quoth Bill Nottingham:
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:
Having a coherent strategy for apps to only need to worry about dropping things in one place would make sense.
- via netreport
- via NetworkManagerDispatcher
- conceivably, via upstart (after all, spawning commands/etc based on events is its raison d'etre)
- (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
Thanks for keeping us informed of the current state of (upstart) affairs.
Hi,
2008/5/22 Bill Nottingham notting@redhat.com:
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
AFAIK it's already in Upstart trunk
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.
FYI /etc/event.d was changed to /etc/init/jobs.d
- 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)
I wanted to do this, but actually initctl is not finished - it will be needed to sending variable values i.e. value of SELINUX_STATE from rcS-check-selinux-state to scripts that depend on SELINUX_STATE.
- 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
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Regards, Michal
BTW. It would be cool if someone created a separate mailing list for Upstart init script "development" and git repository.
Regards, M.
On Thu, May 22, 2008 at 4:04 PM, Bill Nottingham notting@redhat.com wrote:
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
Last time I talked to Scott he had in-progress code to make 0.5 manage the system bus internally. If the system bus depends on syslog and audit those may need to be started too.
- 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
Aren't pretty much all kernel based network filesystems broken in the world of dynamic networking?
On Thu, May 22, 2008 at 04:31:07PM -0400, Colin Walters wrote:
On Thu, May 22, 2008 at 4:04 PM, Bill Nottingham notting@redhat.com wrote:
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
Last time I talked to Scott he had in-progress code to make 0.5 manage the system bus internally. If the system bus depends on syslog and audit those may need to be started too.
- 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
Aren't pretty much all kernel based network filesystems broken in the world of dynamic networking?
Not to mention network based block devices too...
Dan
On Thu, 2008-05-22 at 16:31 -0400, Colin Walters wrote:
On Thu, May 22, 2008 at 4:04 PM, Bill Nottingham notting@redhat.com wrote:
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
Last time I talked to Scott he had in-progress code to make 0.5 manage the system bus internally. If the system bus depends on syslog and audit those may need to be started too.
- 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
Aren't pretty much all kernel based network filesystems broken in the world of dynamic networking?
It depends on what you mean by broken, CIFS for example can handle reconnections ...
Simo.
Colin Walters (walters@verbum.org) said:
- 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
Aren't pretty much all kernel based network filesystems broken in the world of dynamic networking?
I mean, right now we have a static init script that runs once on boot to mount NFS, SMB, etc, and set up network block devices. It's also (in F9) kicked when NM brings up a new default route.
What would be sane is to have it just mount things when it can reach the proper network, and lazily unmount them when that network goes away. Heck, this can be extended to all filesystems - why should you do mount -a to mount /usr/local - why not just have anything in fstab automatically mounted when the device with the proper filesystem signature is found?
Bill
On Thu, May 22, 2008 at 4:44 PM, Bill Nottingham notting@redhat.com wrote:
I mean, right now we have a static init script that runs once on boot to mount NFS, SMB, etc, and set up network block devices. It's also (in F9) kicked when NM brings up a new default route.
What would be sane is to have it just mount things when it can reach the proper network, and lazily unmount them when that network goes away.
The issue with this is that at least last time I checked, at least some file systems like NFS basically don't handle the network going away from underneath them; if you have any userspace processes accessing them they'll be wedged unrecoverably in D state. I gave up long ago on using kernel-based network filesystems on my laptop for this reason.
Simo says CIFS handles this, so maybe other filesystems could be fixed.
But anyways, mounting after the network is available (triggered by NM) makes sense probably.
On Thu, May 22, 2008 at 06:13:23PM -0400, Colin Walters wrote:
On Thu, May 22, 2008 at 4:44 PM, Bill Nottingham notting@redhat.com wrote:
I mean, right now we have a static init script that runs once on boot to mount NFS, SMB, etc, and set up network block devices. It's also (in F9) kicked when NM brings up a new default route.
What would be sane is to have it just mount things when it can reach the proper network, and lazily unmount them when that network goes away.
The issue with this is that at least last time I checked, at least some file systems like NFS basically don't handle the network going away from underneath them; if you have any userspace processes accessing them they'll be wedged unrecoverably in D state. I gave up long ago on using kernel-based network filesystems on my laptop for this reason.
Simo says CIFS handles this, so maybe other filesystems could be fixed.
But anyways, mounting after the network is available (triggered by NM) makes sense probably.
This is a bit dangerours...
Have a look at /etc/init.d/netfs and tell me what will happen if you have an fs marked _netdev and the fsck fails if netfs doesn't run at init but under NM at some random point.
In my opinion you only use netfs for filesystems that you want available at boot and n general you also want them to be always available, processes freezing until the network is available is not a problem but a feature. For everything else that isn't needed at boot there is always autofs.
Starting netfs at some random point after the boot or stopping it isn't a very good idea really, not everyone is running in a laptop.
Kostas
Kostas Georgiou k.georgiou@imperial.ac.uk writes:
On Thu, May 22, 2008 at 06:13:23PM -0400, Colin Walters wrote:
On Thu, May 22, 2008 at 4:44 PM, Bill Nottingham notting@redhat.com wrote:
I mean, right now we have a static init script that runs once on boot to mount NFS, SMB, etc, and set up network block devices. It's also (in F9) kicked when NM brings up a new default route.
What would be sane is to have it just mount things when it can reach the proper network, and lazily unmount them when that network goes away.
The issue with this is that at least last time I checked, at least some file systems like NFS basically don't handle the network going away from underneath them; if you have any userspace processes accessing them they'll be wedged unrecoverably in D state. I gave up long ago on using kernel-based network filesystems on my laptop for this reason.
Simo says CIFS handles this, so maybe other filesystems could be fixed.
But anyways, mounting after the network is available (triggered by NM) makes sense probably.
This is a bit dangerours...
Have a look at /etc/init.d/netfs and tell me what will happen if you have an fs marked _netdev and the fsck fails if netfs doesn't run at init but under NM at some random point.
In my opinion you only use netfs for filesystems that you want available at boot and n general you also want them to be always available, processes freezing until the network is available is not a problem but a feature. For everything else that isn't needed at boot there is always autofs.
Lots of deployments use autofs for file systems that are needed "at boot." Further, autofs will not react favorably if file systems are unmounted out from under it. I agree with the sentiment that, if the network goes down, allow the file system to continue to retry until the network is back online.
Cheers,
Jeff
On Thu, May 22, 2008 at 5:13 PM, Colin Walters walters@verbum.org wrote:
On Thu, May 22, 2008 at 4:44 PM, Bill Nottingham notting@redhat.com wrote:
I mean, right now we have a static init script that runs once on boot to mount NFS, SMB, etc, and set up network block devices. It's also (in F9) kicked when NM brings up a new default route.
What would be sane is to have it just mount things when it can reach the proper network, and lazily unmount them when that network goes away.
The issue with this is that at least last time I checked, at least some file systems like NFS basically don't handle the network going away from underneath them; if you have any userspace processes accessing them they'll be wedged unrecoverably in D state. I gave up long ago on using kernel-based network filesystems on my laptop for this reason.
It should be noted that anything using gnome-vfs, that is, most anything gnome, seems to like to happily stat every mounted filesystem constantly, often for no apparent reason, even if that app isn't even doing anything with that mount. This means your entire desktop locks the f-ck up if an NFS mount goes dead, gnome panel and all. It also seems to prevent automounts from ever timing out.
On Mon, 2008-05-26 at 01:14 -0500, Callum Lerwick wrote: <snip>
It should be noted that anything using gnome-vfs, that is, most anything gnome, seems to like to happily stat every mounted filesystem constantly, often for no apparent reason, even if that app isn't even doing anything with that mount. This means your entire desktop locks the f-ck up if an NFS mount goes dead, gnome panel and all. It also seems to prevent automounts from ever timing out.
That shouldn't happen really. In any case, we're phasing out gnome-vfs. If you see the same problems in gvfs/gio applications, please file a bug, we'd be happy to get it fixed.
Cheers
Bill Nottingham wrote:
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.
This is in place now.
Ability to enable/disable events in a way other than removing the file
(The reasoning for this should be fairly obvious)
Might be a way to do this now with some of the new environment stuff, but a good solid way of doing it should come in 0.5.1. This is my first summer project, should be done by FUDCon latest.
Ability to group events into sets, or profiles
This allows us to handle the sort of behaviors that runlevels are used for sanely.
Comes with above.
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.
We're pretty close to this as of now really. A bit more /etc/rc tweaking will get this.
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)
We're shipping a 900-line shell script. That's the reason.
- Coming up with a sane network notification strategy Right now, we have events kicked off on network changes:
Having a coherent strategy for apps to only need to worry about dropping things in one place would make sense.
- via netreport
- via NetworkManagerDispatcher
- conceivably, via upstart (after all, spawning commands/etc based on events is its raison d'etre)
+1. As soon as more of the DBus stuff appears in trunk (Scott seems to have quite a bit more on his hard drive than he's leaking to launchpad) I'm going to go chat with the NM people about this.
- (possibly) having either upstart 'handle' sysv services more natively or wrap tools such as chkconfig, /sbin/service so they handle both SysV and upstart.
We're going to have a very hard time doing this without effecting the sysv interface.
All clear as mud?
Bill
As clear as an azure sky of deepest summer. You can rely on me, Fred.
--CJD
Casey Dahlin (cjdahlin@ncsu.edu) said:
- 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)
We're shipping a 900-line shell script. That's the reason.
libtool scoffs at you.
Bill
Bill Nottingham wrote:
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.
Might not be entirely related but are we going to get rid of the conflict between network and NetworkManager service by Fedora 10?
Rahul
Rahul Sundaram wrote:
Bill Nottingham wrote:
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.
Might not be entirely related but are we going to get rid of the conflict between network and NetworkManager service by Fedora 10?
Rahul
My understanding is yes.
--CJD
Rahul Sundaram (sundaram@fedoraproject.org) said:
Bill Nottingham wrote:
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.
Might not be entirely related but are we going to get rid of the conflict between network and NetworkManager service by Fedora 10?
What conflict is there? They're using the same configurations...
Bill
Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
Bill Nottingham wrote:
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.
Might not be entirely related but are we going to get rid of the conflict between network and NetworkManager service by Fedora 10?
What conflict is there? They're using the same configurations...
Why is there two different services? IIRC, I can't start both services together in Fedora 9.
Rahul
On Fri, May 23, 2008 at 02:39:37AM +0530, Rahul Sundaram wrote:
Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
Bill Nottingham wrote:
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.
Might not be entirely related but are we going to get rid of the conflict between network and NetworkManager service by Fedora 10?
What conflict is there? They're using the same configurations...
Why is there two different services? IIRC, I can't start both services together in Fedora 9.
Yes you can - just add NM_CONTROLLED=no to the files
/etc/sysconfig/network-scripts/ifcfg-XXXX
that you want NM to ignore.
Dan.
Rahul Sundaram (sundaram@fedoraproject.org) said:
What conflict is there? They're using the same configurations...
Why is there two different services?
NetworkManager does not currently have support for bonding, bridging, VLANs, and similar virtual devices. This can be fixed by getting this support into NetworkManager, but it isn't really related to upstart at all.
Bill
2008/5/22 Bill Nottingham notting@redhat.com:
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.
And why not cooperate with ubuntu and use the upstart scripts that they made? That would leave only a few other ones to make if any at all.
On Fri, 2008-05-23 at 11:31 +0200, Mark wrote:
2008/5/22 Bill Nottingham notting@redhat.com:
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.
And why not cooperate with ubuntu and use the upstart scripts that they made? That would leave only a few other ones to make if any at all.
Given that ubuntu is still using sysv compat mode as well, what scripts do they have for us to re-use?
2008/5/23 Jesse Keating jkeating@redhat.com:
On Fri, 2008-05-23 at 11:31 +0200, Mark wrote:
2008/5/22 Bill Nottingham notting@redhat.com:
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.
And why not cooperate with ubuntu and use the upstart scripts that they made? That would leave only a few other ones to make if any at all.
Given that ubuntu is still using sysv compat mode as well, what scripts do they have for us to re-use?
-- Jesse Keating Fedora -- Freedom² is a feature!
I really thought they used upstart scripts already.. o well than make upstart scripts together with ubuntu. will go twice as fast and both dists will benefit from it. See it as a project Fedora and Ubuntu start (and finish) together.
On Fri, 2008-05-23 at 17:16 +0200, Mark wrote:
I really thought they used upstart scripts already.. o well than make upstart scripts together with ubuntu. will go twice as fast and both dists will benefit from it. See it as a project Fedora and Ubuntu start (and finish) together.
Perhaps you missed the part where we upstream all our changes as best we can.
On Thursday 22 May 2008 21:04:45 Bill Nottingham wrote:
- 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)
Here's one pet peeve of mine (and it's not upstart-specific): why can't udev be made a "real" service that can be shut down or reloaded / restarted via a "service udev restart" method?
Bill Crawford (billcrawford1970@gmail.com) said:
On Thursday 22 May 2008 21:04:45 Bill Nottingham wrote:
- 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)
Here's one pet peeve of mine (and it's not upstart-specific): why can't udev be made a "real" service that can be shut down or reloaded / restarted via a "service udev restart" method?
Why are you needing to restart udev?
Bill
2008/5/27 Bill Nottingham notting@redhat.com:
Why are you needing to restart udev?
Updates libs? I noticed at least one package (I think glibc?) does a "telinit u" after install, so the new libs are used. If something fundamental like that, openssl/gnutls or selinux libs gets updated, I usually restart all the services (so there's no deleted but still referenced files hanging about taking up disk space / ram if nothing else). Yes, I can reboot, but that sorta irritates :o)
-
Bastien Nocera -
Bill Crawford -
Bill Nottingham -
Callum Lerwick -
Casey Dahlin -
Colin Walters -
Conrad Meyer -
Daniel P. Berrange -
Jeff Moyer -
Jesse Keating -
Kostas Georgiou -
M -
Mark -
Rahul Sundaram -
Simo Sorce