Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've written an upstart task that modifies /etc/network/interfaces. (Actually a file sourced into it.) Which start on condition do I need to declare to let my task run before any networking jobs?

I've tried start on starting networking, but that's apparently too late. When I log in after booting I can see that the changes were written, but obviously they are not used: the new config states a static IP, but the boot process waits for a non-existing DHCP server (old config) to time out.

I've also tried start on starting network-interface INTERFACE=eth0, which didn't work either. IIRC there was an error in the log that the change couldn't be written.

Background: I need a VM template that can be cloned and the clones configured through a script. Among other settings, I need to give them a static IP address to access them from the host. I use guestfish to write a config file to one of the virtual disks and let a script apply these settings to the system. I don't want that disk to contain an actual system settings file. I can't modify /etc directly, because that disk is shared (copy-on-write/diff) among the clones and guestfish apparently doesn't support that type of image. I could also let them use DHCP and setup a server that assigns IP by MAC, but I'm afraid of the complexity. I could also add just another virtual disk for configuration files, but if possible I'd prefer to store settings directly on the system disk image.

Used software: Ubuntu Server 12.04, VirtualBox. The configuration modifier is a self written ruby script.

share|improve this question
Have you tried editing rc.local? – Mitch Jun 5 '12 at 8:47
Same problem: failes after two minutes DHCP timeout although the changes appear in the config file. – user1252434 Jun 5 '12 at 9:26

Found a workaround for myself.

I removed any configuration for eth0 from the VM template. Thus it is not brought up automatically. My config job now starts on starting networking, modifies the config file and explicitly calls ifup eth0.

While this solves my problem, this doesn't fit the general case of how to start a service/task in upstart before networking. Thus I'm going to leave the question open.

share|improve this answer
start on starting network-interface
instance $INTERFACE
exec mything


start on starting networking
exec mything

ifup is run by one of two methods, either by the network-interface job or by the networking job, which is used to configure any interfaces not covered by udev.

The instance stanza above makes sure that your job is started for each of the two cases, because the way upstart works, one or condition will not block the other.

(that is this bug btw:

If your job cannot run concurrently or twice, you will need to split it into three jobs. One called 'mything-waiter':

start on starting network-interface
instance $INTERFACE
exec start wait-for-state WAITER=mything-waiter-$UPSTART_JOB-$INTERFACE WAIT_FOR=mything

And another with a similar exec line for starting networking:

start on starting networking
exec start wait-for-state WAITER=mything-waiter-networking WAIT_FOR=mything

And the other called 'mything' which is just

exec mything

I think an argument can be made to have 'start on starting networking' do all of this, but that will require some redesign of the networking bring-up in Ubuntu.

share|improve this answer
I don't understand why, but that job does not seem to be executed at all. I don't see a test file that the job should create (echo .. >> /etc/..) nor do I see a log file in /var/log/upstart/. – user1252434 Jun 28 '12 at 7:40
Note that in the past I believe there were several grave bugs in the scripts above, but I have corrected them after reviewing. So It's likely the previous commenter hit those bugs. – SpamapS Feb 9 '15 at 22:10

Could you simply start your job at start on startup? Is there any reason to tie it to the start of the networks, if you just need the configuration be changed before networking starts.

Edit: ok, that didn't work.

I'm not able to mess up with my init system right now, so I gotta give some advise untested:

First option: add task stanza to your job. It should make Upstart wait until it exits before launching pending networking/network-interface job. I'm fairly sure this isn't fixing the timing issue as there has been plenty of questions in AskUbuntu how to inject stuff into normal boot process.

Second option: use override files. I think network-interface.conf is the one you need to spoof. Sadly it uses pre-start section already, so instead of just making one up we need to copy it (and only it) to our network-interface.override file.

Once you've copied pre-start section, just modify the content to suit your needs. Original file stays as is, but pre-start section from your override literally overrides the one in the original job.

Hope either helps.

share|improve this answer
No, unfortunately this does not work. I've tried to overwrite the config file in a simple test job and according to upstart's log the filesystem is not yet writable at that time. I think the condition needs to be tied somehow to networking anyway, because the config task has to delay network tasks until the changes are completely written. And AFAIK upstart tries to run jobs in parallel if it thinks they are independent, so I have to state that dependency. I had already tried a condition where filesystems are ready and network is starting, but that didn't trigger at all. – user1252434 Jun 6 '12 at 8:15
Sorry for the late reply. I haven't fully tested your second option. I've just let the override add a single comment line into the config file (echo .. >> ..). It could add the line when bringing up lo, but there is no line about bringing up eth0. Upstart's log tells me, that when bringing up eth0 it could not write to the file, because it is on a read only file system. Interestingly it states "cannot create", so it might even still run on initrd at that time. – user1252434 Jun 13 '12 at 7:52
If you're on read-only filesystem at the time it definitely makes it a problem. I'm pretty much out of options if you cannot write until your networking is running ... – Tuminoid Jun 13 '12 at 10:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.