On Mon, Dec 30, 2013 at 09:58:07PM -0800, Josh Triplett wrote: > > But in the real world, we have a lot of services that we just want to start > > in runlevel 2 and be able to trust that the network and disk are sorted. > > This is the classic guarantee that sysvinit gave us pre-udev, but it's > > fallen apart since then because a fast system can get all the way through > > rcS before the kernel has even managed to enumerate all the network devices. > udev didn't break this assumption; this assumption became unreasonable > once people started wanting to dynamically change networks. If you have > a service that can't cope with network interfaces showing up later on, > that same service won't cope with connecting to a new wireless network, > or plugging or unplugging an Ethernet cable. > I've run into this *exact* problem with upstart, and I found it entirely > untenable. You've also said that your experience with upstart was on ChromeOS, not Ubuntu. I'm happy that ChromeOS is using upstart, but it shares almost none of the more recent event policy that would be common to Ubuntu and Debian and is not a useful proxy for understanding how upstart would behave in Debian. Not that I'm sure what you mean by "this exact problem", anyway. The fact that services that don't deal with network changes are problematic? Yes, ok, but I don't see how that has anything to do with using upstart or not, and is not what I was trying to say upstart solved. The more common case, where you need to start a service that listens on a socket, is that it is running on a server and you need to make sure the static network - which, once configured, will not change for the lifetime of the server - is up before trying to start the service. Again, we're all agreed that the server shouldn't be coded that way, but that doesn't change the fact that there are a lot of these daemons out there in packages with init scripts, and we want them to be as reliable as possible. > In any case, systemd does indeed "support" this case; simply make your > service depend on network-online.target, which will block for a > reasonable amount of time to see if a network interface comes online, > and eventually time out if that doesn't occur. This will actually work > even if your primary network is a wireless network managed by > NetworkManager, and even if that network doesn't actually work until the > user has logged in, assuming your service is not actually in the > dependency path of the user logging in. And what makes this work in the case where you *aren't* using NetworkManager? I see no integration with ifupdown in the systemd package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature