upstart not starting init-scripts (event net-device-up IFACE=lo missing)

[pjw]

Since last upstart update, rc-sysinit.conf is not any more starting the init-scripts (i.e. grub-common, which shold reset the recordfail).
upstart Version 0.6.3-11 (0.6.3-10 was working fine).
The only change in rc-sysinit.conf is to wait for "net-device-up IFACE=lo", which means this event never comes!

ProblemType: Bug
Architecture: i386
Date: Wed Dec 16 08:16:54 2009
DistroRelease: Ubuntu 9.10
Package: upstart 0.6.3-11
ProcEnviron:
 LANGUAGE=de_CH.UTF-8
 LANG=de_CH.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
SourcePackage: upstart
Uname: Linux 2.6.31-17-generic i686

SRU JUSTIFICATION:
The fix for bug #461725, a race condition that caused the rc2 runlevel scripts to sometimes be executed before the lo interface is up, has introduced a post-release regression on systems without a proper lo definition in /etc/network/interfaces, whereby the system will not enter runlevel 2 at all. The ifupdown package would previously detect and warn about this case on upgrade, but not correct it. We should unconditionally correct this on upgrade; even if the lo interface will fail to configure because of quirks of the system (e.g., vserver), this isn't a reason not to define it in /e/n/i.

TEST CASE:
1. install upstart 0.6.3-11 and ifupdown 0.6.8ubuntu21 from karmic.
2. confirm that these lines are present in /etc/network/interfaces, and add them if not:
  auto lo
  iface lo inet loopback
3. reboot and confirm that 'runlevel' reports 'N 2'
4. install ifupdown 0.6.8ubuntu21.1 from karmic-proposed
5. confirm that /etc/network/interfaces has not been changed (timestamp, contents)
6. reboot and confirm that 'runlevel' still reports 'N 2'
7. edit /etc/network/interfaces to remove the lines mentioned in step 2
8. reboot and confirm that 'runlevel' does *not* report 'N 2' (I believe it will report 'unknown'?)
9. reinstall ifupdown from karmic-proposed ('sudo apt-get install --reinstall ifupdown')
10. confirm that the lines from step 2 have been re-added to /etc/network/interfaces
11. reboot and confirm that 'runlevel' again reports 'N 2'

[pjw (pjw1965)]

$ initctl list
upstart 0.6.3-10

[pjw (pjw1965)]

$ initctl list
upstart 0.6.3-11

[Ryan Dwyer (ryandwyer)]

I experienced the same problem. I downgraded to 0.6.3-10 and it's working again.

[nicobrainless (nicoseb)]

Same here!

[pjw (pjw1965)]

Solved for me by changing a wrong file /etc/network/interfaces from
auto lo
iface lo inet loopback
 post-up iptables-restore < /etc/iptables.up.rules

to:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
#iface eth0 inet dhcp

Btw. the file /etc/iptables.up.rules does not exist!
All with the same problem should replace /etc/network/interfaces, and confirm, if this solfes it.

[Ryan Dwyer (ryandwyer)]

Solved for me too. I noticed I was missing my /etc/network/interfaces file, so I restored it, changed back to the latest version of upstart and confirmed it's all working correctly.

[lequeux1 (elequeux)]

Fails here also. I downgraded upstart to to 0.6.3-10, works again now. Using Karmic 32bits/PAE

my /etc/network/interfaces (which looks me correct) below:
-------
auto lo
iface lo inet loopback

iface eth0
 pre-up /usr/sbin/ethtool -s eth0 advertise 0x02b
-------

[nicobrainless (nicoseb)]

Mine was already looking like your corrected version...
Everything is still broken :s

[nicobrainless (nicoseb)]

O yes I forgot to mention than downgrading did not work for me, I even got a "seg fault" before mount all at boot!
But I'm on lucid amd64 and 0.6.3-10 is not a lucid package (took it from karmic tree)

[Steve Langasek (vorlon)]

Thank you for reporting this bug and helping to improve Ubuntu.

As noted in comment #6, this happens due to a broken interface configuration. It's undesirable to have such a behavior change for users in an SRU, but upstart itself is not behaving incorrectly here; there is no bug to be fixed in upstart. The most we can do is treat this as a blocker for the SRU publishing. I don't think that's the right tradeoff to make, but I leave that up to the member of the SRU team who will be approving the package.

[pjw (pjw1965)]

@lequeux1 (#8)
>auto lo
>iface lo inet loopback
>
>iface eth0
> pre-up /usr/sbin/ethtool -s eth0 advertise 0x02b

This is also not working on my computer, the following will:
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
 pre-up /usr/sbin/ethtool -s eth0 advertise 0x02b

[Scott James Remnant (Canonical) (canonical-scott)]

No, you're tripping the infamous Upstart bug #447654
(I get no rc scripts either, and I recall from a conversation last week that you don't as well Steve!)

[squarooticus (krose)]

Steve, even with an empty interfaces file, my localhost interface is getting brought up *somehow*:

krose@nausicaa:/etc/network % ifconfig lo
lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:6379496 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6379496 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3878093406 (3.8 GB) TX bytes:3878093406 (3.8 GB)

which means that whatever mechanism upstart is using to receive notifications of interfaces going up or down is not getting all of them. I assume that means one or more of upstart, udev, or NetworkManager is broken. How does upstart receive notification that the interface has been brought up?

[squarooticus (krose)]

Furthermore, if having an empty interfaces file is wrong, then *why do I have one*? I didn't configure it that way: something in Ubuntu back in Jaunty must have, because I've recently reinstalled some of the machines that are currently broken in this manner from scratch with a Jaunty ISO.

[alm (alm)]

Just encountered this bug on a desktop system. After the 0.6.3-11 update, the boot process hung, preventing background daemons like SSH from starting. The contents of /etc/network/interfaces was:
iface lo inet loopback

Adding 'auto lo' fixed it.

This system installed with 8.04 and upgraded to each subsequent release. I'm quite sure that I never messed with interfaces(5), since the network has always been managed by network-manager on this box.

This may technically not be a bug in upstart, but the upgrade is breaking systems, even if the users never messed with upstart or ifupdown. This might be barely acceptable in a release upgrade (with extensive documentation in the release notes), but not in an SRU, IMO. Breaking working systems after release is worse than not fixing a bug.

Is it feasible to automatically fix the broken non-customized interfaces(5) files? Eg. by publishing an ifupdown SRU and making upstart depend on that? Or can we notify the user that they need to fix their interfaces(5) file if they want background daemons and recovery mode to keep working?

[Louigi Verona (louigi-verona)]

Guys, is this bug responsible for some scripts in sysf.conf and modprobe.d to be ignored during boot? I am using an ASUS laptop which has an ambient light sensor problem and I had a script that turned the sensor off on boot - after latest upgrade it stiooed working and I can only turn off the sensor manually from terminal under sudo su. Is this related?

Also - if it is related - can anyone please provide instructions on how to downgrade upstart? I am not a tech guy and I dunno how to do it.

[Steve Langasek (vorlon)]

I don't know what you mean by "sysf.conf", but no, this bug is unrelated to any processing of /etc/modprobe.d.

[Louigi Verona (louigi-verona)]

sysf is a tool that lets you configure some things, in the sys/devices/ folder.

Is there any similar tool that loads scripts of modprobe.d and that might've been screwed up, at least theoretically?

[Steve Langasek (vorlon)]

On Tue, Dec 22, 2009 at 07:56:48PM -0000, Louigi Verona wrote:
> sysf is a tool that lets you configure some things, in the sys/devices/
> folder.

There is no tool of this name in Ubuntu, so I can't say whether this bug
would affect it.

> Is there any similar tool that loads scripts of modprobe.d and that
> might've been screwed up, at least theoretically?

/etc/modprobe.d doesn't contain scripts, it contains configuration options
for the 'modprobe' command. modprobe will be called as needed by udev,
nothing changed here affects that.

--
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/
<email address hidden> <email address hidden>

[Louigi Verona (louigi-verona)]

Yes, well actually guys after I have downgraded to previous version of upstart, my system was restored back to normal. So looks like at least sysf.conf is affected. And other users might have the same problem.

[nieproszenieja (mateusz-szulc)]

I can't use synaptic to downgrade this package (because ssh -X doesn't work any more).
I thought that this:

apt-get install upstart =0.6.3-10

should work, but apt-get said:

root@idaho:/home/mateusz# apt-get install upstart =0.6.3-10
Reading package lists... Done
Building dependency tree
Reading state information... Done
upstart is already the newest version.
E: Couldn't find package

How can I do this with upstart?

[Dmitriy Balakin (0x0000.ru)]

nieproszenieja, apt-get install upstart=0.6.3-10 no space - right way.

[nieproszenieja (mateusz-szulc)]

Thank you very much, now it works.

[Henrik Ingo (hingo)]

Just want to confirm same symptoms and same workaround.

A couple of weeks ago dad's Kubuntu doesn't print anymore.
Recognize that cups isn't running.
Verify that it should be (ls /etc/rc*/*cups)
Diagnose some more, realise that runlevel returns "unknown"
Eventually find this bug
Downgrade to upstart 0.6.3-10 as in comment #23 helps. Runlevel is 2 and cups is running.

Did not edit /etc/network/interfaces at any point above. Downgrading upstart is the only change I did and it fixed the problem.

[Frank Bicknell (fbicknel)]

I just installed 9.10 on a spare drive and sshd would not start on boot; finally found this downgrade upstart to fix (whew).

I noticed Jon White mentioned in comment #9 of a duplicate of this bug (500520):

> Most notably, the system is never put in a proper runlevel even though sulogin pops up and the system *appears* to be running normally.

Funny thing: who -r returns nothing in 9.10!

I installed 9.10 about 5 days ago using the alternate install CD for x86_64 on an AMD machine. Upgrades from the usual suspects applied afterward, then openssh-server installed shortly thereafter. That's when I started down this rathole.

[Ulrich Schreiner (ulrich-schreiner)]

my ssh-service and libvirt-bin service does not start. i downgraded upstart but both services do not start.

it is really a problem, because the system is a server with a few virtual images. everything worked until 9.10. now i have the problem, that i have to start the services manually on reboot.

i have an interfaces file with three bridges (br0-br2) attached to three interfaces (eth0-eth2). i cannot see a problem in the configuration. all bridges are up after reboot, but the services are not, so i think the "networking" works.

i also tried to do a "/etc/init.d/ssh restart" in rc.local. well, the line is executed (you see a "restart" message in the console). but ssh does not work!

[Linatux (sean-voyce)]

downgrading upstart fixed mine - not sure what the real problem is though. Wait & see?

[Alfredo Pironti (alfredo.pironti)]

Please increase the importance of the bug, since it is really critical for remotely administrated server systems! If for any reason the server is rebooted, it cannot be administrated remotely (sshd does not start), nor other services (e.g. web servers, sql servers etc) are started, making the server completely un-operational.

I have two machines affected, both started from 8.04 and always upgraded. Neither of them has a /etc/network/interfaces file, that was deleted at some point, to let network manager operate. Shall I restore the 'interfaces' file for localhost at least? If this is a solution/workaround for the bug, then it should be documented.

[Michael Sidenius (michaelsidenius)]

Here are my observations,

Downgrading does NOT solve my problem.

I DO have a /etc/network/interfaces file:
  cat /etc/network/interfaces
  auto lo
  iface lo inet loopback

My install was directly 9.10 (no upgrade) 64 bit.

uname -a : Linux <name> 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux

service --status-all only shows "ntp" and "pulseaudio" as started (ntp is strange because it should also rely on network)

This bug is also serious because it prevents ordinary users from printing.

Please let me know how I can help debug this (f.inst by adding debug output lines to some files, but which?).

Michael

[Steve Langasek (vorlon)]

If downgrading upstart doesn't solve the problem for you, then you're experiencing an unrelated issue. Please file a separate bug report.

[Alfredo Pironti (alfredo.pironti)]

I added the

auto lo
iface lo inet loopback

lines to /etc/network/interfaces file to one of the two server machines (still no access to the other one, one day downtime now...): now the services are starting up normally at boot -- but network manager disappeared from the control panel (NM service started and network working anyway...)

Nevertheless, I consider this as a workaround. Before modifying "interfaces", localhost interface was correctly set up anyway; moreover, if upstart now really requires these two lines in "interfaces", then this should be done automatically, or the user be warned.

[Alfredo Pironti (alfredo.pironti)]

I managed to have access to a machine where the bug does not show up. That machine has a /etc/network/interfaces file containing exactly the "auto lo \\ iface lo inet loopback" lines.

So this seems to be a relevant clue to bug hunting. In which way this file interferes with localhost being brought up? (in other words: how can we consistently fix this issue, without relaying on user-modified config files?)

[Jason (jason-b-hill)]

This is a serious security bug in my opinion. Many network security processes are started on boot by init via upstart. If you have a server running fail2ban, for instance, and ssh/etc is not set to be dependent on fail2ban with the understanding that fail2ban will be initialized on boot... this leads to a potentially serious situation.

Keep in mind that on a headless server, an update/reboot to this buggy version of upstart may also prevent some main access protocol to the server from being initialized. This is a bad problem.

On 9.10 64-bit, I reverted to 0.6.3.10 and rebooted, to find my system once again initializing everything that it should.

[Brian Burch (brian-pingtoo)]

I have 32-bit ubuntu (I realise this isn't relevant, but I don't want people to get the idea it is a 64-bit problem).

The killer on my own system was bind - when it didn't start all my custom services on the system were completely wrecked. I am surprised bind9 wasn't mentioned by anyone else...

The system had been upgraded in place from jaunty to karmic and was apparently running well. After upgrading upstart, the system was wrecked at the next reboot. I was lucky that I could get to the machine to start the services manually - and VERY lucky someone had already posted this bug and the circumvention. I rolled back upstart and everything returned to normal.

I locked the back-level version so it wouldn't get accidentally upgraded again! I've re-instated the (automatically deleted) /etc/network/interfaces loopback definition. Can anyone say whether it is safe for me to upgrade upstart to 0.6.3-11 again, or are there other problems with this version?

[foxy123 (foxy)]

same here. downgrading seemed to solve it...

[KBios (kbios)]

Same here (cups, kvm). I'm rather surprised this bug isn't marked as critical: we're talking about a large part of operating system services, and this may also produce security issues (firewall not starting etc). At least they could revert to version 0.6.3-10 as a temporary fix.

[Alfredo Pironti (alfredo.pironti)]

Some thoughts about this issue.

1) When no /etc/network/interfaces is available, It seems that upstart is waiting for lo to be brought up before starting services; however network manager, responsible for bringing up lo is not started by upstart; creating the circular dependency.
2) When /etc/network/interfaces is available, some other program, not under upstart control, brings lo up, and everything seems to work.

If this is true, a possible solution to the problem is to let some processes (e.g. NetworkManager) be started by upstart regardless of lo status.

Still I'm not sure 100% about what I'm saying, because in case 1), when the user logs in, Network manager seems to be actually running (or, better, network is properly working, so I assume it's NetworkManager running). So who started netwrokmanager in case 1) ?

[QkiZ (qkiz)]

I have /etc/network/interfaces and upstart not start scripts from /etc/init.d/.

[Alfredo Pironti (alfredo.pironti)]

Does your /etc/network/interfaces file contain the following lines?

  auto lo
  iface lo inet loopback

I have two machines where this workaround is actually working. (But your experience may tell that my hints are in the wrong direction)

Anyway, I agree this bug is in fact critical, and my suggestion is to revert back to the previous version of upstart until the problem is further investigated. What was the intended benefit of this upgrade again?

[oikku (matti-oinas)]

I have lo in interfaces file, /etc/init/network-interface.conf is present, CONCURRENCY=none and latest packages for karmic are installed. And runlevel is unkown. Only way to get this machine to start properly is to downgrade upstart to version 0.6.3-10. As far as I can see this is a bug. If this is the way how bugs are "fixed" in Ubuntu I think it is time to change distribution to something that works and where bugs will be fixed and not just marked invalid.

[Alfredo Pironti (alfredo.pironti)]

Please, even though I, myself started "complaining" about this bug being marked as "invalid", I encourage everyone to respect the developer's effort. He proved himself to be active in solving the bug, and willing to cooperate.

I still do not agree with the current status, and I believe there is a problem of "communication" between the developer assumptions (or expected configurations) and what the users are free to do, without that the operating system warns them about (let's call them) "conflicting configurations".

In fact, can we agree that some complains after the bug becoming invalid stem from the "frustration" of having an "unsupported" configuration (and not being warned about that)? Maybe I'm completely wrong in this point, so please calmly let's discuss on that! :-)

[Steve Langasek (vorlon)]

oikku,

Please post your full /etc/network/interfaces file, and show the output of 'sudo initctl list' in the case where the runlevel is unknown.

Perhaps there is a bug here other than the configuration problems that have been identified, but we'll need more information from you in order to isolate and resolve that bug.

[Christophe Weis (christopheweis)]

I checked my interface file and indeed, an entry was missing.
I corrected it and now the "bug" is also gone for me.

[Leonardo Torok (leotorok)]

It's also possible to solve the problem editing /etc/init/rc-sysinit.conf, changing the line:

start on filesystem and net-device-up IFACE=lo

to:

start on filesystem #and net-device-up IFACE=lo

So it'll no more wait for loopback.

[Steve Langasek (vorlon)]

That's not a solution, that's reintroducing the original bug.

[Steve Langasek (vorlon)]

This should be fixed in lucid and karmic by forcing a correct /etc/network/interfaces on upgrade, so reopening the bug report. upstart is probably not the right package to ship this code; moving to ifupdown.

[Forest Bond (forest-bond)]

For the record, I'd like to see upstart depend on "ifupdown | some-other-package-that-brings-up-lo" since the default upstart configuration requires the loopback interface to be brought up in order to be functional. I know not everyone agrees with this. Maybe it could at least be a recommends.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ifupdown - 0.6.8ubuntu29

---------------
ifupdown (0.6.8ubuntu29) lucid; urgency=low

  * debian/postinst: if the loopback interface is missing from the config in
    /etc/network/interfaces, add it on upgrade; there is no valid use case
    for a system without localhost, and not bringing this up will cause
    upstart runlevel handling to fail. LP: #497299.
 -- Steve Langasek <email address hidden> Fri, 19 Feb 2010 20:29:32 -0800

[Martin Pitt (pitti)]

I reviewed the patch, the logic makes sense. Thanks Steve!

[Martin Pitt (pitti)]

Accepted ifupdown into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Myriam Schweingruber (myriam)]

I get the following when trying to update:

Unpacking replacement ifupdown ...
dpkg: error processing /var/cache/apt/archives/ifupdown_0.6.8ubuntu21.1_amd64.deb (--unpack):
 trying to overwrite '/etc/init.d/networking', which is also in package netbase 0:4.35ubuntu2

[Daniel Holbach (dholbach)]

Seeing the same as #76.

[Daniel Holbach (dholbach)]

http://launchpadlibrarian.net/39438845/ifupdown_0.6.8ubuntu21_0.6.8ubuntu21.1.diff.gz seems to result in:

daniel@miyazaki:~$ debdiff ifupdown_0.6.8ubuntu21{,.1}_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-------------------------------------
lrwxrwxrwx root/root /etc/init.d/network-interface -> /lib/init/upstart-job
lrwxrwxrwx root/root /etc/init.d/networking -> /lib/init/upstart-job

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: net-tools, libc6 (>= 2.7), debconf (>= 1.2.0) | debconf-2.0, [-upstart (>= 0.6.0),-] {+upstart-job,+} lsb-base (>= 1.3-9ubuntu3), netbase (>= 4.30ubuntu2)
Version: [-0.6.8ubuntu21-] {+0.6.8ubuntu21.1+}
daniel@miyazaki:~$

[Martin Pitt (pitti)]

From Daniel:

daniel@miyazaki:~$ debdiff ifupdown_0.6.8ubuntu21{,.1}_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-------------------------------------
lrwxrwxrwx root/root /etc/init.d/network-interface -> /lib/init/upstart-job
lrwxrwxrwx root/root /etc/init.d/networking -> /lib/init/upstart-job

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: net-tools, libc6 (>= 2.7), debconf (>= 1.2.0) | debconf-2.0, [-upstart (>= 0.6.0),-] {+upstart-job,+} lsb-base (>= 1.3-9ubuntu3), netbase (>= 4.30ubuntu2)
Version: [-0.6.8ubuntu21-] {+0.6.8ubuntu21.1+}
daniel@miyazaki:~$

since this is causing a regression, I removed this version from karmic-proposed.

It seems that something in dh_installinit changed since the last ifupdown rebuild in karmic? The actual upload to -proposed did not change anything except code in the postinst.

[Steve Langasek (vorlon)]

Reuploaded, with the debhelper handling also backported from lucid. Sorry about that!

[Martin Pitt (pitti)]

Accepted ifupdown into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Soos Gergely (sogerc1)]

I had the following lines in my /etc/network/interfaces:

auto lo
iface lo inet loopback
    address 127.0.0.1
    netmask 255.0.0.0

but it didn't do anything for me. Downgrading to upstart 0.6.3-10 solved the annoying grub issue (by running grub-common) but sometimes the scripts in /etc/rc2.d have run without the eth0 interface being brought up which was also incorrect. So I have tested the proposed version of ifupdown and it seems to me that it is working correctly. I made 4 test reboots and all of them were successful.

[Soos Gergely (sogerc1)]

I've been using the proposed ifupdown for almost a week and it does what it's supposed to do and I don't see any side effects or bugs.

[Stephen Gildea (stepheng+launchpad)]

I had the same symptoms as this bug when I upgraded to Karmic: my
system would appear to boot ok, but none of the TCP-based servers
would have been started.

After some investigation, I have two suggestions, one for people
trying to debug this problem, the other for the sysv-rc package
maintainers.

For those trying to debug their system after an upgrade, check the
state of your "rc" task:

sudo initctl status rc

You should see task "rc" in state "waiting". If you do, you have a
different case from me (perhaps you are actually hitting this bug),
and my experience will not help you further.

If, like me, you find your rc task still "running", then it is stuck
on something, and you need to figure out what. My next step was to
see what it was currently running:

ps axf | grep -v grep | grep -A8 rc2.d

This will output the subprocess(es) that the /etc/init.d/rc script is
waiting on. Figure out what's holding it up.

In my case, it was hung trying to modprobe for a software modem.
This was left over from an unsuccessful experiment I did years ago.
Apparently this initialization had been broken and hanging on my
system for some time, but previously it didn't interfere with the rest
of the system initialization. I fixed the problem by uninstalling the
software modem package.

Now to my suggestion for the package maintainers. It seems that the
rc manager script assumes that all the "start" scripts it runs will
complete; my case shows that this assumption can be wrong. Perhaps
the rc manager needs to run scripts in the background, updating its
state only when (if) they complete. That way one broken startup
script cannot block the entire system initialization.

I have sysv-rc 2.87dsf-4ubuntu12.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ifupdown - 0.6.8ubuntu21.2

---------------
ifupdown (0.6.8ubuntu21.2) karmic-proposed; urgency=low

  * Backport fix from lucid for the file conflict with netbase that results
    from rebuilding with the current debhelper.

ifupdown (0.6.8ubuntu21.1) karmic-proposed; urgency=low

  * debian/postinst: if the loopback interface is missing from the config in
    /etc/network/interfaces, add it on upgrade; there is no valid use case
    for a system without localhost, and not bringing this up will cause
    upstart runlevel handling to fail. LP: #497299.
 -- Steve Langasek <email address hidden> Mon, 22 Feb 2010 18:17:51 +0000

[David Santamaría Rogado (howl)]

Freshs installation of Lucid lacks of the fix, only upgrades from previous versions solve this. This produce freshs installations of lucid not being able to use printers, this should be fixed as soon as possible.

Thanks.

[Martin Pitt (pitti)]

We can't fix it in lucid final, just in lucid-updates. If you need the fix on an installation medium, you need to wait for Ubuntu 10.04.1, I'm afraid.

[Steve Langasek (vorlon)]

This change was made well before the installation media for lucid was mastered. What are you seeing in /etc/network/interfaces on a fresh lucid install that makes you think it's the same bug? Which method did you use for installing lucid?

[David Santamaría Rogado (howl)]

I said that based on https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/576241/comments/3 but I can see /etc/network/interfaces right in my fresh installation, anyway cups is not started at boot time, but seems to be caused by another thing.

[Luca Aluffi (aluffilu)]

Hi!

Just jumped here from duplicate bug https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/554172?comments=all , so I just "cut&paste" what I wrote on the other bug. My wife complained many times about being not able to print after my dist-upgrade, so my suspects started to rise around grub-upgrade command.

For what is worth I've seen that cups service is not started mostly when there are too many spaces in the kernel's grub command line, e.g:
THIS WORKS: linux /vmlinuz-2.6.32-22-generic root=UUID=a96105c8-5ffd-4962-9f4e-93d87dc58aab ro quiet splash acpi_osi=Linux

THIS MOSTLY NOT (note multiple spaces between "ro" and "quiet"): linux /vmlinuz-2.6.32-22-generic root=UUID=a96105c8-5ffd-4962-9f4e-93d87dc58aab ro quiet splash acpi_osi=Linux

[Zimmer (zimm-z)]

Fresh install to External USB drive.
CUPS intermittently NOT started at boot, particularly will not start from RESTART of system.
Tried installing cups-pdf ,
/var/log/apt/term.log reports " Unpacking cups-pdf (from .../cups-pdf_2.5.0-12_i386.deb) ...
Setting up cups-pdf (2.5.0-12) ...
 * Reloading Common Unix Printing System: cupsd
   ...fail! "
ifupdown version is 0.6.8ubuntu29

[Clownfishy (clownfishy)]

Just come here from bug https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/554172. Cups is not auto starting since I updated with the first major patch release for 10.04. Just updated again and still cups will not auto start. Now have to start it manually every time I want to print.

Can I post any log files which would be of use?

[Steve Langasek (vorlon)]

On Tue, May 11, 2010 at 06:38:18PM -0000, Take Life Easy wrote:
> Can I post any log files which would be of use?

Any log files should be sent to a bug against the cups package, *not* to
this one.

--
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/
<email address hidden> <email address hidden>

[peternickson (peternickson)]

Still unable to print. CUPS Service Stopped.

[Till Kamppeter (till-kamppeter)]

peternickson, your problem is not this bug then but bug 554172.

[Brian Burch (brian-pingtoo)]

I have just resolved a problem with cups not starting about 50% of the time on one of my lucid systems by implementing the circumvention described in https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/604283.

I added the extra lines to /etc/network/interfaces to define a virtual interface lo:0 for the 127.0.1.1 address and have it auto-created early in kernel initialisation. I suspect this solution will apply to any services that need to listen on their own loopback interfaces.

[docsnyderchristoph (docsnyderchristoph)]

My system is an upgraded Ubuntu 10.04 (from 09.04).

I had the same error behaviour: cups did not start with boot time (allthough inserted in /etc/rc.local) but did start manually when entering /etc/init.d/cups start in the terminal

I found the follwoing solution:
when downgrading the package "ifupdown" from Version 0.7~alpha (which was installed during the upgrade) to Version 0.6.8ubuntu29, cups now starts automatically again.

[wodny (z-launchpad-wodny-org)]

Problem exists on one of machines with Lucid 10.04.1.

upstart 0.6.5-7
ifupdown 0.6.8ubuntu29.1

It seams that the "net-device-added" event that should have come from upstart-udev-bridge (caused by a udev event) gets lost somewhere.

In a udev logfile there is:
KERNEL[1285595950.929353] add /devices/virtual/net/lo (net)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/virtual/net/lo
SUBSYSTEM=net
INTERFACE=lo
IFINDEX=1
SEQNUM=1477

UDEV [1285595951.133203] add /devices/virtual/net/lo (net)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/virtual/net/lo
SUBSYSTEM=net
INTERFACE=lo
IFINDEX=1
SEQNUM=1477

But system load hangs at network-interface.conf waiting for net-device-added.

As it was said (for example bug #543506), one can do one of at least 3 things to continue the process:
1) telinit 2
2) initctl emit -n net-device-up IFACE=lo LOGICAL=lo ADDRFAM=inet METHOD=loopback
3) initctl emit net-device-added INTERFACE=lo

But there is one more thing that works:
udevadm trigger
This one seams to replay udev events and net-device-added is noticed.

So for me the most interesting part is to find out why upstart-udev-bridge or upstart loses some events.

As an additional project I've created a upstart start map generator: https://bitbucket.org/wodny/upstart-map
Results attached.

[Steve Langasek (vorlon)]

wodny,

This bug report tracks the bug where the loopback interface failed to be brought up due to a missing /etc/network/interfaces. You appear to be describing a new bug, not previously reported; please open a new bug report for this. If the problem is a missing event from upstart-udev-bridge, you should file this new bug report against the upstart package.

> As an additional project I've created a upstart start map generator:
> https://bitbucket.org/wodny/upstart-map
> Results attached.

Interesting! I bet there would be people on ubuntu-devel interested in knowing about this. BTW, I think the graph needs to express dependencies in more detail; there's no way to tell from this graph which dependencies are "or"ed dependencies, and which are "and"ed dependencies. Even better would be if you could graph the actual events that trigger at boot time by processing /var/log/syslog... (only works if you boot with --verbose)

[wodny (z-launchpad-wodny-org)]

OK, bug report #655145 has been created.

[Elliot K Payen Padilla (epayen)]

Worked for me adding at beginning of /etc/network/interfaces

auto lo
iface lo inet loopback

allow-hotplug eth0
auto eth0
iface eth0 inet static
address xxx.yyy.zzz.sss
.
.
.
(etc)

Thank you every one!

[DiagonalArg (diagonalarg)]

I'm having the same problem: Ubuntu 10.10 on a Dell Dimension 8250. I do have /etc/network/interfaces containing the lines:

auto lo
iface lo inet loopback

But Upstart doesn't launch sshd.

If I run:
sudo service ssh start

I am told that ssh is already running.

If I run:
 sudo /etc/init.d/ssh start
then I get:
 * Starting OpenBSD Secure Shell server sshd [ OK ]

?? Though I'm not too conversant with all this, I thought these two were supposed to do the same thing ??

[DiagonalArg (diagonalarg)]

*
sudo service ssh start
returns with
start: Job is already running: ssh

[Clint Byrum (clint-fewbar)]

DiagonalArg, I think the bug you're experiencing may be bug #531912 , which has only recently been fixed in 11.04. The fix should, however, be backported to 10.10 and 10.04, as indicated by the status of the tasks for Lucid and Maverick.