system services using "console output" not starting at boot

[Mike Basinger]

Binary package hint: cups

Cups is not loading on my machine at boot, must run sudo /etc/init.d/cups start to after booting to print.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: cups 1.4.2-10
ProcVersionSignature: Ubuntu 2.6.32-19.28-generic 2.6.32.10+drm33.1
Uname: Linux 2.6.32-19-generic i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Fri Apr 2 13:07:35 2010
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100401)
Lpstat: Error: command ['lpstat', '-v'] failed with exit code 1: lpstat: Connection refused
MachineType: Dell Inc. Studio XPS 1340
Papersize: letter
PpdFiles: Brother-HL-2170W-series: Brother HL-2170W Foomatic/pxlmono (recommended)
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-19-generic root=UUID=615bbe85-506a-4152-af5a-a5c2da303d83 ro quiet splash
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: cups
dmi.bios.date: 09/08/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A11
dmi.board.name: 0Y279R
dmi.board.vendor: Dell Inc.
dmi.board.version: A11
dmi.chassis.asset.tag: 1234567890
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A11
dmi.modalias: dmi:bvnDellInc.:bvrA11:bd09/08/2009:svnDellInc.:pnStudioXPS1340:pvrA11:rvnDellInc.:rn0Y279R:rvrA11:cvnDellInc.:ct8:cvrA11:
dmi.product.name: Studio XPS 1340
dmi.product.version: A11
dmi.sys.vendor: Dell Inc.

[Brock Riedell (kbrcbc)]

I confirm the same behaviour ever since installing Lucid 10.04 beta 1 on a Lenovo ThinkPad T400. CUPS does not start up on booting; requiring a manual start with "sudo service cups start".

[Garry Roseman (forestmoonsilence)]

Same problem exists on Lucid 10.04 beta 1 (updated as of 4/11) running on a Zotac IONITX / Intel Atom 230. Printer is connected by USB and is turned off at boot time -- turning the printer on and rebooting does not help. After every reboot cups is not running.

[Till Kamppeter (till-kamppeter)]

Can you attach the file

/var/log/boot.log

Does the file /etc/rc.d/S50cups exist for you

ls -l /etc/rc2.d/S50cups

[Till Kamppeter (till-kamppeter)]

Can you also have a look at bug 497299, perhaps your problem is the same.

[Mike Basinger (mike.basinger)]

Re-installing all cups-* packages fixed the problem for me. I will do a fresh install again for the Lucid RC release, to see if this is still an issue.

[Mike Basinger (mike.basinger)]

lrwxrwxrwx 1 root root 14 2010-04-01 10:23 /etc/rc2.d/S50cups -> ../init.d/cups

[Mike Basinger (mike.basinger)]

The problem has returned.

[Garry Roseman (forestmoonsilence)]

None of the comments points me toward a solution.

runlevel
N 2

garry@Hiro:~$ ls -l /etc/rc2.d/S50cups
lrwxrwxrwx 1 root root 14 2010-04-01 13:49 /etc/rc2.d/S50cups -> ../init.d/cups

I have not tried downgrading Upstart yet --- if a race condition exists I'm guessing that it may be a race on disk i/o; I have a humdrum 1.6 GHz cpu / 3.2 GB memory much like many others (Zotac IONITX / Intel Atom 230 with Nvidea GPU) but maybe faster than average disk i/o (Intel X25 M 80GB SSD on SATA2). That could "reveal" a race condition that others do not see. The problem did not occur on this system until I installed this SSD and simultaneously installed the Lucid Beta-1.

I reinstalled all of cups with no joy. Cups does not run on boot and I can not get it to run following any of the advice that has been posted so far.

[Garry Roseman (forestmoonsilence)]

Here's a further clue:

exactly the same problem occurs on my personal computer --- IONITX with Intel Atom 330, 3.2 GB memory, _and_ an even faster SSD, the Intel X25E. CUPS worked fine on that computer under Karmic; it was upgraded to Lucid when Beta 1 was released and the cups daemon has been failing to start since then.

Good luck bug hunters! This might be a tough one. It is real. Find it!

p.s. of course if it IS caused by a dreaded race condition then of course it sometimes goes away when software is re-installed or any odd change is made that happens to change the timing of events at boot time.

[pinch150g (rob-mcdole)]

I am having the same problem. I have tried all of the above with no help.

[Pascal De Vuyst (pascal-devuyst)]

Thanks for your bug report.
All people with this problem please attach the file /var/log/apt/term.log

[Brock Riedell (kbrcbc)]

Pascal,
Here is the requested log file. Since I originally reported that this
bug was affecting me, routine Lucid Beta updates have partially resolved
the problem for me -- i.e., on some reboots cups starts up fine; on
others I have to start it manually.

Regards
Brock Riedell
<email address hidden>

On 10-04-17 03:48 AM, Pascal De Vuyst wrote:
> Thanks for your bug report.
> All people with this problem please attach the file /var/log/apt/term.log
>
> ** Changed in: cups (Ubuntu)
> Status: Confirmed => Incomplete
>
>

[Garry Roseman (forestmoonsilence)]

Here's the requested term.log --- after several updates the problem went away on both of my machines and cups printing just worked, and then the updates of the last few days brought the problem back and I'm sad again :-<

After a reboot neither computer is running cups even though examining the init script setup shows that it should be running cups. This means for the moment that my wife generally can not print because she does not have sudo privilege and wouldn't know how to start a service anyway.

[Pascal De Vuyst (pascal-devuyst)]

Nothing special in the term logs.
Do you get more information in /var/log/boot.log if you boot with "quiet splash" options removed as described here: https://help.ubuntu.com/community/Grub2#Editing%20Menus%20During%20Boot

[Garry Roseman (forestmoonsilence)]

Removed the "quiet splash" options from the grub config and rebooted. Now THAT looks like a linux system. :-D

boot.log is attached. There's nothing interesting there. cups is not mentioned in dmesg.

But I did grep for "cups" in all of my system logs for the past couple of days and was surprised to find that cupsd did segfault last night, apparently while or after I printed some xmonad/dzen documentation to the local networked printer (to read on my night shift :-)

In syslog.1 I find this entry:

Apr 24 21:44:10 Medium kernel: [18688.981257] cupsd[4938]: segfault at 0 ip 0027c7a0 sp bfebbb88 error 4 in libc-2.11.1.so[209000+153000]

Of course cups had been started manually on the command line on both the client and server computers :-(

21:44 would be about the moment that I shutdown my computer so I think that the segfault may have occurred during the shutdown process rather than during printing. I doubt that this segfault relates to this bug 554172 but it is the first error message I have seen regarding cups. The daemon has been silently failing to run at boot time.

[Garry Roseman (forestmoonsilence)]

The last time cups loaded at boot time I saw these messages in kern.log

kern.log.1:Apr 21 06:52:06 Medium kernel: [ 7.215772] type=1505 audit(1271850726.855:13): operation="profile_load" pid=934 name="/usr/lib/cups/backend/cups-pdf"
kern.log.1:Apr 21 06:52:06 Medium kernel: [ 7.216856] type=1505 audit(1271850726.859:14): operation="profile_load" pid=934 name="/usr/sbin/cupsd"

Since Apr 21 there are no such messages in kern.log about loading cupsd or cups-pdf. All that changed in my configuration after Apr 21 was routine updates. According to what I see in kern.log cupsd was loading properly on Apr 19, 20, and 21, but not before or after. cupsd managed to run during the window of 3 days before another update spoiled it again. (I update my system daily.)

[Joshua Martin (jsmartin)]

This problem occurs on a fresh install of Ubuntu 10.04 x86 final. Had to perform sudo /etc/init.d/cups start in order to install printer.

[Patrick Vijgeboom (patrick-vijgeboom)]

I re-installed all the CUPS-* packages and this solved my problem. I don know why or for how long but it worked.

[Mario Vukelic (kreuzsakra)]

I upgraded a friend's system from Ubuntu 8.04 to 10.04 and the same problem occurs. I don't have access to that system right now, but I'll try the reinstall too. If any one is interested in any details I should capture before doing so, please let me know.

[cdyring (clausdyring)]

term.log

[Tom Inglis (tominglis)]

I can confirm that this issue affects me on Mythbuntu 10.04. I reinstalled the cups package using Synaptic, and it seems to have corrected the problem.

[Nils Naumann (nau)]

This is probably a dupe of bug #497299. In order to test it the runlevel has to be cheked, and if the runlevel is undefined, the file /etc/network/interfaces should be checked, if it contais the lines:

auto lo
iface lo inet loopback

The ceation of this file has solved the issue at my system.

[Till Kamppeter (till-kamppeter)]

Should not be caused by CUPS that CUPS does not get started.

[Luca Aluffi (aluffilu)]

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

[Luca Aluffi (aluffilu)]

Uhm...

the other duplicate fellows ( https://bugs.launchpad.net/bugs/497299) told us to get back here, and they are right since their bug is for ifupdown.

Could someone remove the duplicate status from this bug?

[Steve Langasek (vorlon)]

Right, this is not a duplicate of bug #497299. Un-duping and reassigning back to cups - there's nothing at all here pointing at an upstart problem.

[Zimmer (zimm-z)]

FWIW . I WAS using the NOUVEAU video driver for my NVIDIA card.

I have installed the NVIDIA proprietary driver and have spent last 2 hours rebooting and booting from cold. CUPS now starting at boot ! I will continue to monitor the situation.

[Joel Kelley (cmdrfierce-deactivatedaccount)]

I also have this problem. I would like to add that it's intermittent -- sometimes I will boot up and CUPS is started. This post in the forums describes it well: http://swiss.ubuntuforums.org/showthread.php?p=9281178

[E. Lewis (ed-lewis)]

For what it is worth, I have same problem on my 32-bit Lucid machine. I do not have he problem on my 64-bit Lucid machine. CUPS starts properly on the 64-bit. It starts intermittently on boot on the 32-bit. As observed by others "sudo service cups start" starts CUPS on the 32-bit after booting.

[Diez B. Roggisch (deets-web)]

I can add that on my dad's machine (upgraded from 8.04 to 10.04 yesterday, 32bit) the problem happens with an hplib-based printer when the printer is *not* turned on on boot.

If it is turned on, cups is started + a HP-logo appears in the gnome sys tray.

"sudo service cups start" works as well of course. Then no HP-logo appears, but printing is ok.

[isolationism (kevin-isolationism)]

I did a brand new install of 10.04 on this laptop and am affected by the same bug. Manual start works, but everything else I've tried doesn't (including attempting to restart cups in local.start -- it was worth a shot).

For a seasoned Linux user like me this is no big deal. For my wife who is new to Linux (and whom does not have wheel access on this device to prevent her from doing anything potentially destructive), it's a deal-breaker to have to call me over every time she wants to print something.

[Paul Done (pkdone-hotmail)]

I'm on brand new 10.04 install. Sometimes cupsd starts for me, sometimes it doesn't. However, since then I've realised that there are other jobs also intermittently/randomly starting or not starting. As a result, perhaps this is not cups specific and is a general problem as highlighted at https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/543506 ?

[David Santamaría Rogado (howl)]

Sorry about the dupicate state, I put it on all the cups not starting bugs on lucid after reading someone having it running at boot by only creating the loopback interface.

Now with loopback interface at default in ifupdown seems that we are still lacking cups at boot.

[Zimmer (zimm-z)]

Reporting Back!!
CUPS still intermittent... will NOT usually start from cold boot but is more likely to start from RESTART ...

[fig_wright (fig-wright)]

I have this problem also. Can start cups manually. Also cups starts automatically manually by running telinit!

 ~ > sudo runlevel
Unknown

 ~ > sudo telinit 2
 ~ > sudo runlevel
N 2

~ > sudo initctl list

Warning: Fake initctl called, doing nothing.

~ > service --status-all
 [ ? ] acpi-support
 [ ? ] acpid
 [ ? ] alsa-mixer-save
 [ ? ] anacron
 [ - ] apparmor
 [ ? ] apport
 [ ? ] atd
 [ ? ] avahi-daemon
 [ ? ] binfmt-support
 [ - ] bluetooth
 [ - ] bootlogd
 [ - ] brltty
 [ ? ] console-setup
 [ ? ] cron
 [ ? ] cryptdisks
 [ ? ] cryptdisks-early
 [ ? ] cryptdisks-enable
 [ ? ] cryptdisks-udev
 [ + ] cups
 [ ? ] dbus
 [ ? ] dmesg
 [ ? ] dns-clean
 [ ? ] ecryptfs-utils-restore
 [ ? ] ecryptfs-utils-save
 [ ? ] failsafe-x
 [ - ] fancontrol
 [ ? ] gdm
 [ ? ] gkrellmd
 [ - ] grub-common
 [ ? ] hostname
 [ ? ] hwclock
 [ ? ] hwclock-save
 [ ? ] irqbalance
 [ - ] kerneloops
 [ ? ] killprocs
 [ - ] lm-sensors
 [ ? ] module-init-tools
 [ ? ] network-interface
 [ ? ] network-interface-security
 [ ? ] network-manager
 [ ? ] networking
 [ ? ] nmbd
 [ ? ] ondemand
 [ ? ] pcmciautils
 [ ? ] plymouth
 [ ? ] plymouth-log
 [ ? ] plymouth-splash
 [ ? ] plymouth-stop
 [ ? ] pppd-dns
 [ ? ] procps
 [ + ] pulseaudio
 [ ? ] rc.local
 [ - ] rsync
 [ ? ] rsyslog
 [ - ] saned
 [ ? ] screen-cleanup
 [ ? ] sendsigs
 [ ? ] smbd
 [ ? ] speech-dispatcher
 [ ? ] stop-bootlogd
 [ ? ] stop-bootlogd-single
 [ ? ] ubiquity
 [ ? ] udev
 [ ? ] udev-finish
 [ ? ] udevmonitor
 [ ? ] udevtrigger
 [ ? ] ufw
 [ ? ] umountfs
 [ ? ] umountnfs.sh
 [ ? ] umountroot
 [ ? ] unattended-upgrades
 [ - ] urandom
 [ ? ] wpa-ifupdown
 [ - ] x11-common

[polarbeardog2 (polarbeardog-2)]

I can confirm that I have had this issue from just before upgrading to 10.04 from 9.10. I am able to get printing functionality back when I run 'sudo /etc/init.d/cups start' but this needs to be done every time the computer is booted. I have also run 'sudo update-rc.d cups enable' and the service was confirmed added but absent from the subsequent boot.

[Corrado (corrado-zanella)]

Same intermittent problem.
'sudo /etc/init.d/cups start' works

[cdyring (clausdyring)]

I also have the problem using an atom cpu and ssd harddisk.

I am using two usb printers, attached via a usb hub.

Also, the printer trouble shooting wizard in the printer administration app detects that cups is not running, but it then the directs me to a menu item in the system menu which does not seem to be there... system->administration->services .. this app should supposedly allow the user to start the service. Maybe it is the locale translaation that is bad, but I can not see any such menu item.

[Nick Davis (argoneus)]

I updated to upstart 0.6.5-7, rebooted, and have the same issues with services not starting. Specifically, nginx doesn't start, and I have two CGI services that interact with nginx, that don't start on boot. I've checked with rcconf, and all 3 are labelled to start on boot. Checking some of the logs (/var/log/messages, /var/log/syslog, and /var/log/boot{.log}) doesn't reveal anything that would indicate a problem with these services, as far as I can tell.

A related issue, that I mentioned earlier, is that 'shutdown -r now' doesn't work. I get the "System is shutting down" message on my console, but nothing happens. I have to use 'reboot', and this seems to work consistently. From some of the Ubuntu forum conmments, it seems like this is possibly related to the upstart problems.

[Robbie Williamson (robbiew)]

For anyone who is still experiencing problems with services not starting at boot, I suggest you open a new bug (feel free to subscribe me - robbie.w is my ID). There could be any number of reasons why a particular service won't start, and we'd rather you open a new bug than add to this one. If we determine the issue is the same, we will just dup your bug to this one.

Thanks,
Robbie

[ingo (ingo-steiner)]

On my box it helped to just un-install plymouth and all services like cups, apcupsd ... are starting fine since then.
How to perform this (artificial blocked) un-install, see https://bugs.launchpad.net/bugs/556372

[Rogi (rogi)]

Just deinstalling plymouth solves this problem on my system too.

[ingo (ingo-steiner)]

Great, thanks for your feedback, Rogi.

Plynouth in my opinion is yust a fancy boot screen which is still in an alpha stadium. Though Ubuntu team always points out it also does all logging during boot process - that is the root cause of all that and other troubles and you again did confirm that. Did you ever see any fsck properly logged in /var/log/fsck/* with Lucid?

The ugly side is that Canonical has intenionally built in a fake-dependency on plymouth in packages 'mountall' and 'cryptsetup' to force users to act as alpha/beta-testers for their buggy plymouth. I'd be willing to do such tests (to make Ubuntu better) if it is clearly explained and documented and the choice to participate is left to the user. But I do not accept the current attitude in a LTS-release!

This are hard words of a disappointed Ubuntu user and I do revoke my statements if somebody proves the opposite.

[Anthony Glenn (aglenn-pcug)]

The revised version of Upstart fixed it for me. Thanks to Scott James Remnant and Andy Whitcroft. I have done many cold boots and restarts since the fix, and the bug is gone.

To avoid problems with Plymouth, get rid of "quiet splash" in the Grub kernel command line. Alas, Grub and Grub 2 are different. The following instructions apply to Grub.

Start a root terminal. Enter:

grub-install -v

You should get the response "0.97". That is the Grub version number. If it reads "1.96" or higher, you have Grub 2, check the documentation at:

https://help.ubuntu.com/community/Grub2

Assuming you have Grub, edit /boot/grub/menu.lst , find the line like:

# kopt=root=UUID=87c74523-fd13-4bca-97e4-5aba28218222 ro quiet splash

Notice that the 32 hex digits on your UUID will be different to mine. Keep your own. Delete "quiet splash".

Look down further in the file and you will find a line like:

kernel /boot/vmlinuz-2.6.32-24-generic root=UUID=87c74523-fd13-4bca-97e4-5aba28218222 ro quiet splash

Delete the "quiet splash". Save the file. Restart the computer. Now you should have a Linux boot that looks like a Linux boot, with real console messages and none of that wimpy graphical splash screen rubbish. However, then your graphical interface (X Windows) will start normally.

Feel proud.

[ingo (ingo-steiner)]

> To avoid problems with Plymouth, get rid of "quiet splash"

Better: get rid of Plymouth

[Nick Davis (argoneus)]

>For anyone who is still experiencing problems with services not starting at boot, I suggest you open a new bug (feel free to >subscribe me - robbie.w is my ID). There could be any number of reasons why a particular service won't start, and we'd rather >you open a new bug than add to this one. If we determine the issue is the same, we will just dup your bug to this one.

>Thanks,
>Robbie

I've created a new bug, as requested, detailing the issues I'm still experiencing regarding services not starting on boot. I've subscribed you to the bug (https://bugs.launchpad.net/ubuntu/+bug/642555).

[Marcus Bointon (marcus-synchromedia)]

I'm running the updated upstart and plymouth-free grub2 config on two newly installed amd64 boxes (bog-standard Dell 2950s) with today's 2.6.32-24-server kernel, and I'm still finding a whole bunch of services fail to start (cron, apache2, mysql, fail2ban, sysstat, postfix, openntpd, mysql-mmm), along with the unknown runlevel issue. All of them (except sysstat for some reason) start fine if I run telinit 2. One of them reported the localhost interface breakage, but the other did not.
It doesn't seem likely that all of these major, common packages have bugs with identical symptoms - it's got to be a problem with upstart - so reporting bugs on the packages is probably a waste of time.
This is a really major problem as it can (and does for us) render servers non-functional and insecure by default - why is it marked as 'wontfix' and downgraded from critical with no obvious pointer to a better bug?

[Steve Langasek (vorlon)]

On Tue, Sep 21, 2010 at 04:09:39PM -0000, Marcus Bointon wrote:
> I'm running the updated upstart and plymouth-free grub2 config on two
> newly installed amd64 boxes (bog-standard Dell 2950s) with today's
> 2.6.32-24-server kernel, and I'm still finding a whole bunch of services
> fail to start (cron, apache2, mysql, fail2ban, sysstat, postfix, openntpd,
> mysql-mmm), along with the unknown runlevel issue. All of them (except
> sysstat for some reason) start fine if I run telinit 2. One of them
> reported the localhost interface breakage, but the other did not.

If the runlevel is not set at boot, the issue you're seeing is unrelated to
this bug. The rc-sysinit job is failing to trigger, either because you have
filesystems configured in /etc/fstab that are not being found and mounted at
boot time, or because you don't have a properly configured loopback
interface in /etc/network/interfaces.

> It doesn't seem likely that all of these major, common packages have bugs
> with identical symptoms - it's got to be a problem with upstart - so
> reporting bugs on the packages is probably a waste of time.

Yes, in that case the appropriate thing to do would be to file a *single*
bug against upstart describing the problem. In any case, following up to
this bug, which has been fixed, is not the correct approach.

> This is a really major problem as it can (and does for us) render servers
> non-functional and insecure by default - why is it marked as 'wontfix' and
> downgraded from critical with no obvious pointer to a better bug?

What is marked as 'wontfix' for the lucid and maverick releases is the
kernel issue that led to this problem. The user-facing issue has been
addressed.

--
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>

[David Haskins (surfari)]

I cannot see that this has been fixed. I am using 10.04 LTS on my Toshiba Tecra and do Apache development. Most times but not alawys, on boot apache2 does not start so I need to do it manually "sudo /etc/init.d/apache2 start"

[John Edwards (john-cornerstonelinux)]

David Haskins, could you run the 'runlevel' command to check if this is related to this particular bug, or if it is another problem?

[Mike Bianchi (mbianchi-foveal)]

On Wed, Jan 12, 2011 at 03:14:41PM -0000, John Edwards wrote:
> David Haskins, could you run the 'runlevel' command to check if this is
> related to this particular bug, or if it is another problem?

A better approach might be to put logging into /etc/init.d/apache2
and figure out:
 If it is actually called.
 And, if it is, why does it fail.

I freely admit my prejudices on the this type of problem.

 /bin/init under upstart does not guarantee the order of execution of the
startup scripts. In fact it almost forces them to be random if you have a
multi-core processor. (Again this is my prejudice, based on my prior problems
with upstart).

I strongly suspect that there is some service that /etc/init.d/apache2
depends upon that is sometimes completely started when it runs, and
sometimes is not. Since upstart runs /etc/init/* services
depending on the "start on" prerequisite "event" list being _exactly_ right,
if I didn't know about one or more, or got the "start on" stanza slightly wrong
I saw unreliable service starts.

My two cents: I think it would be good to have access to an old fashion,
one-step-at-a-time boot sequence (as an option).
I would gladly give up boot speed for boot sequence certainty. I do not
see a way to do that with upstart. Boot sequence certainty was easy to
accomplish when everything was started by numbered filenames under
 /etc/init.d .

I commented on the lack of upstart event documentation in other bug reports:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/543506/comments/45
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/543506/comments/46
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/543506/comments/49

[ingo (ingo-steiner)]

Probably things will turn better in future, Scott will leave Canonical and go to Google by next week, leaving behind the half done upstart in Ubuntu for others to clean up.

[David Haskins (surfari)]

I get:
$ runlevel
N 2
whatever that means.

Luckily my remote production unattended 64bit virtual Ubuntu 10.04 LTS server seems to start Apache, MySQL and SSH when it boots otherwise this would be a disaster. Why do this kind of thing in a LTS release?? Doesn't anyone understand the words "server" "stable" "conservative" - next time I meet Mark Shuttleworth (he has an honorary doctorate from my University) I tell him this is ANOTHER fault caused by unnecessary fiddling by youths. The last one was about Tomcat clobbered by a missing catalina-ant link.

[ingo (ingo-steiner)]

@David,

try executing following command (simulates upgrade of libc6):

apt-get install --reinstall libc6

and shutdown you server, then check your root-filesystem,
or reboot and check with "cat /var/log/messages | grep orphan"

That's Bug #672177

[John Edwards (john-cornerstonelinux)]

David, if you get runlevel 2 it means that you have a different problem to this bug (which is about upstart not entering runlevel 2).

If it only effects Apache than I would suggest opening a new bug against that relevant Apache package (if one does not already exist). If it does turn out to be an upstart bug then it can reassigned to that package.

You might also want to try some of the suggestions in this and related bug reports, such as commenting out the "console output" lines in the files in the /etc/init/ directory.

As for your other comments, Ubuntu servers are package-stable for LTS releases, but not as conservative as Debian or Red Hat - that is one of the reasons why Ubuntu exists. I run over 50 Ubuntu servers and only 1 machine was effected by the upstart bug, and that was 9 years old and only used for testing. That fact that only one of your machines has this problem does point to it be a little obscure and not something that is commonly met.

[Jens Schødt (jens-schoedt)]

Any news on this bug? Is anyone trying to fix it?

Considering moving to an other distro without upstart....

[John Edwards (john-cornerstonelinux)]

Jens Schødt, this bug is in the kernel console device not being writeable early enough in the boot. I appears to be in upstart because that is the first thing that tries to write to it. A work around has been available of the problem for several months, which seems to have fixed the boot for those people who reported to this bug.

So if you have a fully updated machine and still see problems like 'runlevel' reporting 'N' then I recommend you put the details of your problem in a new bug report and place a link to this bug report as a possible duplicate (but don't mark as confirmed duplicate).

[Brian J. Murrell (brian-interlinx)]

On Sat, 2011-02-12 at 12:11 +0000, Jens Schødt wrote:
> Any news on this bug? Is anyone trying to fix it?
>
> Considering moving to an other distro without upstart....

Yeah, IMHO, upstart was waaaaayyyy rushed into Ubuntu. It was clearly
not ready considering how many problems it has caused for anyone not
running a configuration that fits within what has got to be some pretty
narrow testing scenarios (i.e. desktop systems with the entire system in
a single partition?)

I guess it wouldn't have seemed so bad if it were not taking literally
many months and several releases to fix the problems. Again, IMHO it
was a mistake to put it in so soon. But everyone makes mistakes, that's
fair enough. But when one does make a mistake, the right thing to do is
get all hands on deck so that your mistake does become other people's
problem.

Just my $0.02.

[Jens Schødt (jens-schoedt)]

Thanks John,

I see problems in a fresh 10.10 install (both 32 and 64bit). init.d services are not always started. eg. hostapd and sabnzbdplus.
I dont know about the 'runlevel' reporting 'N' because I am currently trying an other distro without this problem. I will create a bug if I get back to it.

[Mike Bianchi (mbianchi-foveal)]

> > On Sat, Feb 12, 2011 at 02:15:20PM -0000, Brian J. Murrell wrote:
> > Any news on this bug? Is anyone trying to fix it?
> On Sat, 2011-02-12 at 12:11 +0000, Jens Schødt wrote:
> Yeah, IMHO, upstart was waaaaayyyy rushed into Ubuntu. ...

I agree.

The evidence strongly suggests that Upstart still is not ready for prime time.

So may I suggest, at the very least, /bin/init be give an detailed logging
function that announces _everything_ it does, and _why_, into syslog
with the _option_ of quieting it if someone sees the need to save the file
space. By "_everything_ it does" I mean not only starting and stopping.
I mean announcing that it is waiting on some event for some /etc/init/*.conf
stanza. Announcing every event that arrives and (if it can) from where.

As I see it the problem is that nobody can present clear evidence of why
their favorite start-up script is not performing as expected because you
have to go in and instrument (read "put print statements into") everything
that upstart touches. Then, if it doesn't touch something you have to
guess a probable cause, hack, and reboot.

This problem has a long history that looks like inattention out here in
user land.

The evidence is that it IS NOT FIXED .

And don't put it off as a kernel or somewhere else.
When Ubuntu does not work, it is Ubuntu that is not working.

And, if a fix still eludes you, put back an old fashioned /bin/init with the
old fashioned /etc/init.d/S??<startupscript> sequence,
at least as an option.

I am still on 8.04 because this is not fixed.

I also am looking to go straight Debian or elsewhere.

[Brian Rogers (brian-rogers)]

Upstart has been working fine for me ever since the patch for this bug.

If you're still experiencing the symptoms in a closed bug report, the best thing to do is file a new bug. Otherwise fixing the remaining bug isn't on anyone's to-do list, and it's kind of silly to complain that it isn't being done.

[Clint Byrum (clint-fewbar)]

On Sat, 2011-02-12 at 21:22 +0000, Mike Bianchi wrote:
> > > On Sat, Feb 12, 2011 at 02:15:20PM -0000, Brian J. Murrell wrote:
> > > Any news on this bug? Is anyone trying to fix it?
> > On Sat, 2011-02-12 at 12:11 +0000, Jens Schødt wrote:
> > Yeah, IMHO, upstart was waaaaayyyy rushed into Ubuntu. ...
>
> I agree.
>
> The evidence strongly suggests that Upstart still is not ready for prime
> time.
>

Ready or not its out there in RHEL and Ubuntu as well as other places.

>
> So may I suggest, at the very least, /bin/init be give an detailed logging
> function that announces _everything_ it does, and _why_, into syslog
> with the _option_ of quieting it if someone sees the need to save the file
> space. By "_everything_ it does" I mean not only starting and stopping

[Steve Langasek (vorlon)]

On Sat, Feb 12, 2011 at 09:22:20PM -0000, Mike Bianchi wrote:
> > > On Sat, Feb 12, 2011 at 02:15:20PM -0000, Brian J. Murrell wrote:
> > > Any news on this bug? Is anyone trying to fix it?
> > On Sat, 2011-02-12 at 12:11 +0000, Jens Schødt wrote:
> > Yeah, IMHO, upstart was waaaaayyyy rushed into Ubuntu. ...

> I agree.

> The evidence strongly suggests that Upstart still is not ready for prime
> time.

This is not a forum for general gripes about how upstart works. It is a bug
report about a specific issue, /one which has been resolved/.

If anyone is having problems with getting an init script to start up
reliably at boot time on your system, please file a new bug report against
the upstart package in Ubuntu.

> I am still on 8.04 because this is not fixed.

As has been stated repeatedly by the developers, *this* bug is fixed, and by
your own admission you are not in a position to provide feedback about any
further issues with startup in Ubuntu releases that use native upstart jobs
by default. If you had an actual bug to report regarding boot reliability,
you would find the Ubuntu developers very responsive to the issue. But you
aren't reporting a bug, you're instead repeating hearsay about boot being
unreliable with upstart when the record does not support this. Please do
not abuse the bug reporting system for general complaints about the
technology decisions that have been made in Ubuntu. Please *do* file new
bug reports for outstanding issues in upstart or elsewhere.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world

[Mike Bianchi (mbianchi-foveal)]

We users are NOT experts in the Launchpad rules and regulations.
We just want our problems addressed.

Please do whatever is necessary to open up a bug that addresses the
long standing and still present condition of init scripts not being executed
reliably.

For "Title" and "Description" I propose:

        Boot service starts are sometimes, randomly, unreliable.
        Execution of /etc/init/* and /etc/init.d/* boot scripts sometimes fail.

        Since the introduction of the upstart version of /bin/init we continue
        see unreliable boot sequences where it appears boot scripts in
  /etc/init/ and /etc/init.d/ are not always executed to completion.

  Bug #554172, Comment #295 2011-02-12
                "... in a fresh 10.10 install (both 32 and 64bit). init.d
                services are not always started. eg. hostapd and sabnzbdplus."

        It is crucial to note that evidence suggests
                the behavior is somewhat random, and
                that it appears to be more prevalent on multi-core processors.

        This bug was once thought to be based on the "console output" stanza in
         /etc/init/*.conf noted in Bug #554172 and duplicates, but ongoing
        evidence is that the problem has not been completely solved.

I ask this based on the following observations from this bug (#554172) ...

> John Edwards wrote on 2011-02-12: #293
> Jens Schødt, this bug is in the kernel console device not being writeable
> early enough in the boot.

This bug's Description starts with:
   "Cups is not loading on my machine at boot, must run sudo /etc/init.d/cups
   start to after booting to print."

It became titled 'system services using "console output" not starting at boot'
later on when that seemed to be the root cause of all the problems.

While the "console output" fix improved the situation it obviously is not
the complete solution.

> Steve Langasek wrote on 2011-02-12: #299
> If anyone is having problems with getting an init script to start up
> reliably at boot time on your system, please file a new bug report against
> the upstart package in Ubuntu.
> :
> ... *this* bug is fixed, ...

> Jens Schødt wrote on 2011-02-12: #295
> I see problems in a fresh 10.10 install (both 32 and 64bit). init.d services
> are not always started. eg. hostapd and sabnzbdplus.

To my mind, Jens is saying "this bug still exists in 10.10", and that while
this _bug_ is marked "Fix Released", the evidence is that the _problem_ is not.

There are 20 duplicates to this bug, some going back to 9.10 in early 2010.
And that says to me that adding another bug which will just get marked
"possible duplicate" (John Edwards, comment #293) and it will again not
be investigated or attended to.

In bug 642555: (we can see this problem has a long and convoluted history)
> Colin Watson wrote on 2010-11-22: Comment #10
> The thing is that we don't know what the root cause of this problem
> (i.e. the one at the start of this bug report) is. Without data, it's
> just speculation. At the moment, we haven't proven that your missing
> boot messages actually have anything to do with services not starting -
> the link is only circ...

[Clint Byrum (clint-fewbar)]

On Mon, 2011-02-14 at 15:13 +0000, Mike Bianchi wrote:
> We users are NOT experts in the Launchpad rules and regulations.
> We just want our problems addressed.
>
> Please do whatever is necessary to open up a bug that addresses the
> long standing and still present condition of init scripts not being executed
> reliably.
>
> For "Title" and "Description" I propose:
>
> Boot service starts are sometimes, randomly, unreliable.
> Execution of /etc/init/* and /etc/init.d/* boot scripts sometimes fail.
>
>
> Since the introduction of the upstart version of /bin/init we continue
> see unreliable boot sequences where it appears boot scripts in
> /etc/init/ and /etc/init.d/ are not always executed to completion.
>
> Bug #554172, Comment #295 2011-02-12
> "... in a fresh 10.10 install (both 32 and 64bit). init.d
> services are not always started. eg. hostapd and sabnzbdplus."
>
> It is crucial to note that evidence suggests
> the behavior is somewhat random, and
> that it appears to be more prevalent on multi-core processors.
>
> This bug was once thought to be based on the "console output" stanza in
> /etc/init/*.conf noted in Bug #554172 and duplicates, but ongoing
> evidence is that the problem has not been completely solved.
>
>
> I ask this based on the following observations from this bug (#554172) ...
>
> > John Edwards wrote on 2011-02-12: #293
> > Jens Schødt, this bug is in the kernel console device not being writeable
> > early enough in the boot.
>
> This bug's Description starts with:
> "Cups is not loading on my machine at boot, must run sudo /etc/init.d/cups
> start to after booting to print."
>
> It became titled 'system services using "console output" not starting at boot'
> later on when that seemed to be the root cause of all the problems.
>
> While the "console output" fix improved the situation it obviously is not
> the complete solution.
>

Mike, sorry about my earlier reply, some of it got cut off by how
launchpad handles quoted email. Steve said some of what I was saying.

The request to create a new bug report, marking it as possibly related,
is a common practice and it has proven useful in the past to get things
fixed.

Right now the issue that was reported originally is definitely fixed
from the point of view of many of those who reported they were affected
by it, and from the point of view of the developer(s?) who found and
applied a fix.

Some of the duplicates/comments may not be related to what was fixed
there, but its not helpful to anyone to keep pounding on this bug
report, even if some of the original reporters were actually not this
bug.

So I agree with Steve, and recommend that users who are affected by a
similar problem (even if its not easily or predictably reproducible),
report a new bug, and post here saying "I reported bug X, possibly
related to this one".

Then users experiencing this problem will see that comment, go to that
bug, and possibly see that their issues are more closely related to that
problem, and hopefully help by adding some data p...

[Garry Roseman (forestmoonsilence)]

On Mon, Feb 14, 2011 at 11:56 AM, Clint Byrum <email address hidden> wrote:

>
> Right now the issue that was reported originally is definitely fixed from
> the point of view of many of those who reported they were affected

I took Ubuntu 10.04 off my little home network because of this bug after
suffering with it for too long and trying all "fixes". I don't know if the
bug would still persist on my machines with the latest Ubuntu but a flaw in
the startup code is not something I would tolerate for long. (I came to
Ubuntu from NetBSD --- you know it's reputation for quality --- and moved on
from Ubuntu to Archlinux which has worked out well for me).

[Mike Bianchi (mbianchi-foveal)]

On Mon, Feb 14, 2011 at 05:56:44PM -0000, Clint Byrum wrote:
> The request to create a new bug report, marking it as possibly related,
> is a common practice and it has proven useful in the past to get things
> fixed.
>
> Right now the issue that was reported originally is definitely fixed
> from the point of view of many of those who reported they were affected
> by it, and from the point of view of the developer(s?) who found and
> applied a fix.

I am one of those who saw the same problem in 10.04 in mid-2010 that many
others were and are reporting. It still isn't fixed.
No matter what the status of this bug says, it still is not fixed.

See
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554172/comments/295

It seems the only way to get the attention of the developers that there is a
problem is to generate a detailed bug report, but /bin/init does not give
enough logging information to prove the case.

You want evidence of the bug?
Give us the ability to generate the detailed log files that will let us demonstrate it.

Please!

[Steve Langasek (vorlon)]

On Mon, Feb 14, 2011 at 03:13:57PM -0000, Mike Bianchi wrote:
> Please do whatever is necessary to open up a bug that addresses the
> long standing and still present condition of init scripts not being executed
> reliably.

No, we do not proxy create bug reports. The user /experiencing the problem/
should open a bug report. Bug reports are an important tool for developers
to have a dialogue with the user in order to isolate and resolve bugs. That
doesn't work if the user isn't part of that dialogue.

> For "Title" and "Description" I propose:

> Boot service starts are sometimes, randomly, unreliable.
> Execution of /etc/init/* and /etc/init.d/* boot scripts sometimes
> fail.

That is a generic title that only underscores the disconnect here. You are
starting from the assumption that there is some general bug in upstart that
causes boot scripts to be unreliable. There is no evidence of this. We
have in the past identified bugs that had such an effect, and those have
been fixed. For the vast majority of users, boot in Ubuntu is now reliable.

Any bug report about remaining boot problems should be *specific* in its
description of the problem. If there is a general bug, the developers can
extrapolate from the specific to the general. But if you can't give
specifics, it's not a bug report at all - it's a rumor.

> Bug #554172, Comment #295 2011-02-12
> "... in a fresh 10.10 install (both 32 and 64bit). init.d
> services are not always started. eg. hostapd and sabnzbdplus."

The author of comment #295 says he is not currently in a position to help us
debug this problem and that he will file a bug report if and when he is
able. Once again, there is no need to proxy creation of a report.

I understand that some people are still finding their boot unreliable. But
there is no evidence that it's related to *this* bug report, and these boot
reliability problems are not reproducible for any of the developers. We
want to help make Ubuntu more reliable for users but the first step in doing
that is for the affected users file bug reports for their specific issues
and *not* misuse this bug report for that purpose.

[ingo (ingo-steiner)]

> I understand that some people are still finding their boot unreliable. But
there is no evidence that it's related to *this* bug report, and these boot
reliability problems are not reproducible for any of the developers. We
want to help make Ubuntu more reliable for users but the first step in doing
that is for the affected users file bug reports for their specific issues
and *not* misuse this bug report for that purpose.

Please also consider that meanwhile (almost 1 year after release of LTS-Lucid) people including me get tired in submitting bug reports which after some months probably get marked "won't fix in Lucid', "incomplete", "will fix in Natty" or whatever.

I meanwhile switched to Debian-Squeeze => all troubles gone, very similar to Lucid, but reliable.

[penalvch (penalvch)]

Mike Basinger, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[dino99 (9d9)]

That version is now outdated and no more supported

[Brian J. Murrell (brian-interlinx)]

> That version is now outdated and no more supported

Waiting for the Ubuntu versions that bugs are filed against to just become unsupported is one way to close tickets I suppose. Even tickets that affect 243 people.

[penalvch (penalvch)]

Brian J. Murrell, this report hasn't had a comment from an original reporter since 2013, and the latest duplicate report filed was back from Lucid.

Hence, could you please advise precisely on why this report should remain open?

[Brian J. Murrell (brian-interlinx)]

@Christopher: I wasn't suggesting it should stay open. I was just making a comment on how letting tickets stagnate until everyone gives up and stops commenting is one sure way to close tickets.

I don't actually use Ubuntu any more because my experience when I last did (and the reason I switched) was that this was just too routine. People file tickets and they just wait and wait until either everyone gives up that it will be fixed or it eventually gets fixed upstream... meanwhile people have to live (sometimes for a long time) with the bug. This ticket did after-all take 6 years from when it was opened to finally getting closed.

So you can go ahead and [re-]close if you like. I won't notice or care one way or the other. I just wish Ubuntu was better maintained is all and that the lack of decent maintenance didn't force me to switch distros.

[FrankStefani (too-clever)]

Unbelievable: After many years with Ubuntu-12.04 to 16.04, followed by Linux Mint up to 19.3 (Ubuntu 18.04), I switched to a fresh new install of Lubuntu-19.04 a week ago... and have this strange printer disappear problem for the first time ever!

Today is May 18th, 2019 - that is over threet years(!!!) after the last entry in this list.

How can that be? What's wrong?

--------------------------

My printing system for the last 12-15 years based on cups with the following setup:

* 1 network laser printer
* 3 "symbolic" printers which are a copy of the former, to set defaults for particular uses: "monoprinter" (grayscale), "colorprinter" (full color) and "labelprinter" (use of manual feed)

# lpstat -s
device for Brother_MFC_9142CDN: ipp://BRN30055C78CF3B.local:631/ipp/print
device for colorprinter: ipp://BRN30055C78CF3B.local:631/ipp/print
device for labelprinter: ipp://BRN30055C78CF3B.local:631/ipp/print
device for monoprinter: ipp://BRN30055C78CF3B.local:631/ipp/print

# ls -l ppd/
total 96
-rw-rw-r-- 1 root lp 8619 May 12 18:07 Brother_MFC_9142CDN.ppd
-rw-rw-r-- 1 root lp 8619 May 12 18:07 Brother_MFC_9142CDN.ppd.O
-rw-r----- 1 root lp 8617 May 17 21:00 colorprinter.ppd
-rw-r----- 1 root lp 8635 May 17 20:56 colorprinter.ppd.O
-rw-r----- 1 root lp 8622 May 17 21:05 labelprinter.ppd
-rw-r----- 1 root lp 8622 May 17 21:01 labelprinter.ppd.O
-rw-r----- 1 root lp 8620 May 17 20:59 monoprinter.ppd
-rw-r----- 1 root lp 8635 May 17 20:58 monoprinter.ppd.O

Besides the different settings in /etc/cups/printers.conf, the DeviceURI is the same for all four while the UUID differs:

<Printer Brother_MFC_9142CDN>
UUID urn:uuid:f81a64b6-71d2-3878-71cf-1b1fd6b4dba3
DeviceURI ipp://BRN30055C78CF3B.local:631/ipp/print
</Printer>
<Printer colorprinter>
UUID urn:uuid:63efeecc-be6e-3065-6c0c-9a73bdd0dd62
DeviceURI ipp://BRN30055C78CF3B.local:631/ipp/print
</Printer>
<Printer labelprinter>
UUID urn:uuid:756313d5-4548-327f-666b-9f2edf2c8942
DeviceURI ipp://BRN30055C78CF3B.local:631/ipp/print
</Printer>
<DefaultPrinter monoprinter>
UUID urn:uuid:c4abcfb1-c1f2-34fd-4e8f-514209e3e5e9
DeviceURI ipp://BRN30055C78CF3B.local:631/ipp/print
</DefaultPrinter>

Any help / hint / solution is highly appreciated - TIA.

[Steve Langasek (vorlon)]

Your comment describes an issue entirely unrelated to this bug report. Please file a separate bug report against the cups package using ubuntu-bug cups.

[penalvch (penalvch)]

FrankStefani, given the scope of this closed report was fixed in Ubuntu 10.10 (i.e. pre-dating your usage of 12.04), it had and has nothing to do with your problem.

However, regarding the problem you are experiencing, it is most helpful if you use the computer the problem is reproducible with and file a new report by running the following from a terminal:
ubuntu-bug cups

Also, please feel free to subscribe me to it.

[FrankStefani (too-clever)]

Thanks for directing me - see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829644