After upgrade to karmic cups server do not start.

[Paweł T. Jochym]

Binary package hint: cups

After standad upgrade from jaunty (the previous installation was made from scratch and it was not modified too much) the cups daemon does not start any more. I can start it with "/etc/init.d/cups start" and it works fine. I can print and see network printers etc. But the upstart scripts do not start it as they should.

ProblemType: Bug
Architecture: i386
CupsErrorLog: E [06/Oct/2009:11:54:23 +0200] Unable to remove temporary file "/var/spool/cups/tmp/.hplip" - Is a directory
Date: Tue Oct 6 15:55:32 2009
DistroRelease: Ubuntu 9.10
Lpstat:
 device for DESKJET-930C: ipp://10.111.1.2:631/printers/DESKJET-930C
 device for DESKJET_930C: ipp://10.111.1.2:631/printers/DESKJET_930C
MachineType: LENOVO 6477W9D
Package: cups 1.4.1-4
Papersize: a4
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-11-generic root=UUID=3d7d9f0b-29c2-418b-ba95-789b2f04ce07 ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=pl_PL.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-11.38-generic
SourcePackage: cups
Uname: Linux 2.6.31-11-generic i686
dmi.bios.date: 09/01/2008
dmi.bios.vendor: LENOVO
dmi.bios.version: 7TET34WW (1.08 )
dmi.board.name: 6477W9D
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr7TET34WW(1.08):bd09/01/2008:svnLENOVO:pn6477W9D:pvrThinkPadX300:rvnLENOVO:rn6477W9D:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 6477W9D
dmi.product.version: ThinkPad X300
dmi.sys.vendor: LENOVO

[Till Kamppeter (till-kamppeter)]

This is an upstream problem of HPLIP. The "hp" backend of HPLIP creates a directory in the /var/spool/cups/tmp/ directory, probably to save configuration data there. This breaks the start-up process of CUPS.

To the developers at HP: This is a design bug. CUPS filters and backends should never create a configuration directory or file while executing a print job or doing the printer discovery for CUPS. If they need a configuration file, it should be put into /etc/... already during the installation of the HPLIP package. The file should be system-wide and world-readable (so that the filters and backends can read it when running as the system user "lp"). If the filters or backends do not find a configuration file they should use default values without trying to save them in a new configuration file. Note that the filters and backends run as the user "lp" which has very limited rights, especially only file system access to the spool area for the jobs.

[David Suffield (david-suffield)]

Till,
The "hp" backend creats no .hplip directory.

Something (hal_lpadmin?) must be calling a hp-xxx command which probably creates the .hplip directory at cups restart.

The commands hp-makeuri and hp-info are intended to be run by users only. I would try to use the hp-mkuri command for system services.

The hp-mkuri is written in C and does not have the overhead of the python based hp-xxx commands.

[Johannes Meixner (jsmeix)]

FYI, we have had a similar issue, compare
https://bugzilla.novell.com/show_bug.cgi?id=339443

Usually a .hplip directory is created by whatever hp* program
in the home directory of the user who runs it (if this directory
does not yet exist).

If the user "lp" runs whatever such hp* program,
a .hplip directory is created in lp's home directory
which is e.g. in openSUSE 11.1:
----------------------------------------------------
root@host # su - lp
lp@host $ cd
lp@host $ pwd
/var/spool/lpd
----------------------------------------------------

[Johannes Meixner (jsmeix)]

And guess what there is on my openSUSE 11.1 workstation:
--------------------------------------------------------------------------
lp@host $ ls -la ~
total 16
drwxr-xr-x 3 lp lp 4096 2009-10-07 10:15 .
drwxr-xr-x 13 root root 4096 2009-08-12 15:15 ..
-rw------- 1 lp lp 17 2009-10-07 10:15 .bash_history
drwxr----- 2 lp lp 4096 2009-01-13 14:46 .hplip
--------------------------------------------------------------------------

[Johannes Meixner (jsmeix)]

From my current point of view there are two bugs:

 1.
Backends and filters in HPLIP should not leave any
files and/or directories in the system (i.e. clean up all
what tey might have created).

2.
CUPS should do a more rigorous clenaup of his own
directories (i.e. "rm -rf" instead of only a plain "rm")
to remove intentionally any leftover stuff.

[Johannes Meixner (jsmeix)]

My /var/spool/lpd/.hplip directory was created a longer time ago.
I cannot remember which HPLIP version I did run at 2009-01-13.
Currently I run HPLIP 3.9.8.
I removed the /var/spool/lpd/.hplip directory manually.
It did not re-appear,
neither after running /usr/lib/cups/backend/hp
nor after printing both via the hpijs and hpcups drivers
nor after set up of an additional queue with hp-setup (as root).
Currently I cannot reproduce how it gets created.

[Till Kamppeter (till-kamppeter)]

Under Jaunty and Karmic there are no CUPS filters, backends, or PPD generators which call any command line tools of HPLIP ("grep hp- /usr/lib/cups/*/*"). system-config-printer calls "hp-info" and "hp-makeuri", both are called as the user who called system-config-printer (interactive GUI mode) or root (non-interactive Plug'n'Print mode, /lib/udev/udev-configure-printer), so the hp-* tools seem never to get called by the "lp" user.

For the migration of Python-based hp-* tools to hp-mkuri I would need the following features in hp-mkuri:

1. If the device has fax capabilities also the fax URI needs to get reported back
2. Capability check for a printer model before CUPS queue setup, equivalent to 'hp-info -x -i -d"<uri>"'

[wizard10000 (wizard10000)]

I too have this problem. Subscribing to bug ;-)

[Till Kamppeter (till-kamppeter)]

The 'Unable to remove temporary file "/var/spool/cups/tmp/.hplip" - Is a directory' is not the reason why CUPS does not start. On my system the directory also exists and also the error in error_log but CUPS started without problems after every update of the CUPS package.

[Cyril Jaquier (cyril-jaquier)]

I'm also affected by this bug in karmic since a few days/weeks. I strongly suspect upstart (or another package related to the new boot process). I noticed that some if not all scripts in /etc/rc2.d/ are not executed on boot.

ondemand is not executed. The governor is now set to "performance" instead of "ondemand" on my laptop.
virtualbox-ose is not executed. The virtualbox kernel modules are not loaded at boot time.

Starting the scripts manually always works (ondemand, virtualbox-ose, cups, etc).

[Till Kamppeter (till-kamppeter)]

Cyril, thank you for your comment. This looks really like the reason for the bug.

As many services which did not get migrated to upstart do not start on your system, the problem seems to be upstart's default configuration and not bugs in the individual services. This is not a CUPS bug.

Subscribing Scott James Remnant for further investigations. Scott, please assign the bug to the correct package.

[Till Kamppeter (till-kamppeter)]

I have moved the HPLIP discussion to bug 452134, please continue that discussion there.

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

I have no time to investigate this, and I don't see any evidence of an Upstart problem here - all of the services you're referring to are sysvinit services/initscripts still

[Cyril Jaquier (cyril-jaquier)]

I opened a new bug against the sysv-rc package. Bug #453473.

[cement_head (andorjkiss)]

This is a bug with the October 26th updates

[Cyril Jaquier (cyril-jaquier)]

Today I purged upstart, sysv-rc and insserv, reinstall them and it now works as expected. cups, ondemand, virtualbox-ose, etc are started during the boot process. Something went probably wrong during the alpha phases.

[cement_head (andorjkiss)]

Hmm, I'll try Cyril's fix and post back.. I just upgraded from Jaunty.

This WILL BE a major showstopper for a lot of people.

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

EDIT: Cyril, how did you manage to do this without uninstalling the entire O/S? Please post a workaround.

- CH

[cement_head (andorjkiss)]

Hi Cyril,

Need some help. I tried a "reinstallation" of the three packages (upstart, sysv-rc and insserv) and got and Error 2 sysv-rc. Now during a reboot there is a very long pause - 5 minutes where the machine is trying to find a list of modules to load a boot. How do I fix this?

Thanks,
Andor

[cmcginty (casey-mcginty)]

Hitting this bug now along with pulseaudio not starting (and others??). Seems like a serious issue to me. Is this going to be fixed before the final release? I don't see how 9.10 can break all of the old services and still be released as is??

[Cyril Jaquier (cyril-jaquier)]

Mmhhh... I shouldn't have post this as uninstalling upstart, sysv-rc and insserv may break your system. Here is more or less what I did:

$ sudo dpkg --purge --force-all upstart sysv-rc insserv

Notice the --force-all flag so you should really know what you are doing.

sysv-rc complained about some scripts not being able to "register" (or something else) into the sysv-rc. I don't remember exactly but you should also get the warning. The "reconfigure" trick suggested in this message did not help so I finally reinstalled or even removed those packages (I don't remember exactly).

$ sudo aptitude reinstall the_package

or

$ sudo dpkg -r --force-all the_package

The idea is to completely remove upstart, sysv-rc and insserv from your system and reinstall them. I then had to install sysv-rc manually:

$ sudo dpkg -i /var/cache/apt/archives/sysv-rc_2.87dsf-4ubuntu11_all.deb

and finally install all the missing dependencies with aptitude again.

DO NOT REBOOT YOUR SYSTEM before you get upstart, sysv-rc and insserv installed again. So again, I don't recommend to do this if you don't know what you are doing and if you don't know how to recover your system.

Pulseaudio should start on a per-user session. So I don't think the pulseaudio issue is related to this one.

[cement_head (andorjkiss)]

Ha, yeah...well...I just did a dual boot with a fresh version of Karmic and am transfering my files over. Its definitely beyond me, plus I now have the ultrafast ext4 file system. Thanks anyway!

[Schmitt (cv-schmitt)]

Hello workaholics,

I have this problem like you. What should I do next ???
Output is looking as if there is missing a library ???
Here:
-------------------------------------
nux-76c3:/home/dschinn/Desktop/hplip-3.9.8 # make
/bin/sh ./libtool --tag=CC --mode=link gcc -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -g -O2 -version-info 1:0:0 -o libsane-hpaio.la -rpath /usr/local/lib/sane libsane_hpaio_la-hpaio.lo libsane_hpaio_la-mfpdtf.lo libsane_hpaio_la-pml.lo libsane_hpaio_la-scl.lo libsane_hpaio_la-io.lo libsane_hpaio_la-common.lo libsane_hpaio_la-sanei_init_debug.lo libsane_hpaio_la-marvell.lo libsane_hpaio_la-soapht.lo libsane_hpaio_la-soap.lo libsane_hpaio_la-xml.lo libhpip.la libhpmud.la -L/lib -ldbus-1 -lcups -ldl -lsane -lcrypto
/usr/bin/grep: /usr/lib/libgphoto2.la: No such file or directory
/usr/bin/sed: can't read /usr/lib/libgphoto2.la: No such file or directory
libtool: link: `/usr/lib/libgphoto2.la' is not a valid libtool archive
make: *** [libsane-hpaio.la] Fehler 1
linux-76c3:/home/dschinn/Desktop/hplip-3.9.8 #
-------------------------------------
I have Suse 11.1 and hplip 3.9.8
For help thank you very much !!!
Greetings
Schmitt.

[eZFlow (breakdevize)]

does anyone know an easy workaround so cups get started at boot?

[John Burkhart (jfburkhart)]

affected, subscribing. Would it be a possible fix to simply rename the cups start script so that it starts later? As, after all, it does seem to start just fine manually...

[eZFlow (breakdevize)]

i found what was causing my problem.

enter: sudo gedit /etc/init.d/rc

change CONCURRENCY to none, not startpar or shell because that doesnt work in karmic.

[Thawn (webmaster-korten-privat)]

eZFlow's method does not work for me. I am also affected, but in my /etc/init.d/rc Concurrency is already set to none.

[Thawn (webmaster-korten-privat)]

correction:
for me the problem is actually twofold: sharing printers via cups over the local network does not work any more since the upgrade from jaunty to karmic but the cups service seems to be running.
sharing printers via samba does not work, because samba complains that it cannot find the cups service:

/var/log/smbamba/log.smbd:
[2009/11/10 19:44:48, 0] smbd/server.c:1068(main)
  smbd version 3.4.0 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2009
[2009/11/10 19:44:48, 0] printing/print_cups.c:103(cups_connect)
  Unable to connect to CUPS server localhost:631 - Connection refused
[2009/11/10 19:44:48, 0] printing/print_cups.c:103(cups_connect)
  Unable to connect to CUPS server localhost:631 - Connection refused
[2009/11/10 19:44:49, 0] smbd/server.c:456(smbd_open_one_socket)
  smbd_open_once_socket: open_socket_in: Address already in use
[2009/11/10 19:44:49, 0] smbd/server.c:456(smbd_open_one_socket)
  smbd_open_once_socket: open_socket_in: Address already in use

if I manually restart samba, printer sharing via samba seems to work.

[Thawn (webmaster-korten-privat)]

another addition, sorry:
I found out, that for me the first problem mentioned above was actually not with cups but, that avahi does not announce the cups printers properly any more.
the samba problem remains

[Borja López Soilán (NeoPolus) (borjals)]

We have a customer with this bug: since he updated some packages on 2009-12-03 cups won't start on boot (he hadn't updated since 2009-11-09).

If we run "sudo /etc/init.d/cups start" it starts without problems. We found that the "/etc/init.d/cups" script is simply not run on boot! (there is no "Starting Common Unix Printing System" on logs), so everything points to upstart :(

He is using Ubuntu Karmic 9.10 32bit installed from the ground (not an upgrade).

[nicobrainless (nicoseb)]

I am hit by this bug too, but I think it is not related to cups only.
see bug #453473
https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/453473?comments=all

[MagicVince (vincent-mabillot-gmail)]

I'm also affect:
no automatic start of the cups server, but no problem if I start it manually.

It appears with karmic
I noticed the problem after rebooting with my new printer (samsung laser color with samsung linux driver) that I added to a HP PSC1210 that i still continue to use as scanner only (printing sucks...).

[Simon Porter (portersb)]

Ditto: In fact, looking at BootUp-Manager, only ntp and pulseaudio start; every other daemon (including cups and samba) fail to do so, but will if called directly by sudo. So (in my case at least) this appears to be a fairly wide-reaching problem.

I'm running a fresh install of 32-bit Karmic, installed with debootstrap/chroot.

[Borja López Soilán (NeoPolus) (borjals)]

Simon, after some work we found this:

- With upstart there is no boot logging (it's not supported yet!; /var/log/bootlog is empty), so if some daemon from "/etc/init.d" fails to load it may leave no trace.

- With upstart in Karmic, some services (scripts in /etc/init) run in parallel. But scripts from /etc/init.d are run in sequence (the sequence defined on /etc/rcX.d/ where X is the runlevel; /etc/rc2.d/ by default):
     + If any script in /etc/rc2.d/ freezes (in an infinite loop or deadlock), the next scripts won't be run. That means that, for example, if postfix (S20) deadlocks, other daemons like cups (S50) and cron (S89) won't start.
     + X and the login manager (gdm) are loaded in parallel with those /etc/rcX.d scripts, so the user does not see the /etc/rc2.d/ scripts output, and won't notice if some script is crying for help.

So in the end the problem is: If any daemon fails to load *before* cups, you might not see any error message and it may not leave any log message; you will just notice that cups is missing.

[Lars Ola Liavåg (l-liavag)]

I also have this problem. CUPS doesn't start on boot. It happened after one of the more recent updates (I now have CUPS 1.4.1) on both my desktops running Karmic (fresh installs). No problems until less than a week ago.

I've searched the web and found this and other threads about people having similar problems, but no solution yet. This is a major issue for me and probably others who try to promote Ubuntu as our main system in the family (I dual boot for the sake of my son's gaming...).

[HaraldK (pifpafpuf)]

Welcome to the brave new world of Ubuntu==Microsoft Windows. In the old days, I could simply watch the system boot. Any hickup would be noticed easily and the cause could be investigated. Today, karmic covers everything with a boot splash, things go wrong underneath badly but we pretend everything is alright only to notice much later, that the boot process is broken. Instead of having really many people in the world seeing what is wrong and report the bug (the real advantage of open source), we only get tons of messages like above: it does not work and I cannot see a thing.

Sorry for the rant.

Can anybody just tell me how to get rid of the silly boot splash in order to see what the system is doing? I am sure the cause is then easily found.

Thanks,
Harald.

[HaraldK (pifpafpuf)]

Ok, found it myself:

apt-get install startupmanager

Run it, get rid of the boot splash and make sure to activate "show text during boot".

Harald.

[PWM (pwm)]

I was able to fix one case according to this : http://joeb454.ubuntuforums.org/showthread.php?p=8455909 I.e. By changing cups start-up status with sysv-rc-conf. Similarly this could also fix some other of those init issues.

Must be some glitch in some install scripts ..

I must advice against the "Cyril Fix" - It's dangerous and not straightforward .. and in addition it probably won't fix the problem. (And the original advice is not accurate enough.)

[PWM (pwm)]

Update : Unfortunately the "fix" wasn't permanent.
After the first boot everything was working OK. But then cups doesn't start after subsequent boots.
Meanwhile /var/spool/cups/tmp/.hplip has emerged from somewhere. And /var/log/cups/error_log now contains "Unable to remove temporary file "/var/spool/cups/tmp/.hplip" - Is a directory".
(The system does not have any HP hardware whatsoever.)

Manually removing the .hplip drirectory again fixes the situation for one boot only ..

Manually running "/etc/init.d/cups start" always works regardless the .hplip directory.

[ddave01 (ddave01)]

Yes, I have upgraded from 9.04 to 9.10 (64bit) and experiencing the same as PWM. above.

dpkg -l |grep HP for printing gives;
ii hpijs 3.9.8-1ubuntu2 HP Linux Printing and Imaging - gs IJS drive
ii hpijs-ppds 3.9.8-1ubuntu2 HP Linux Printing and Imaging - HPIJS PPD fi
ii hplip 3.9.8-1ubuntu2 HP Linux Printing and Imaging System (HPLIP)
ii hplip-data 3.9.8-1ubuntu2 HP Linux Printing and Imaging - data files
ii hplip-gui 3.9.8-1ubuntu2 HP Linux Printing and Imaging - GUI utilitie

ddave01

[Lars Ola Liavåg (l-liavag)]

I got it working on one of my two computers by using sysv-rc-conf to add run level S to the CUPS entry. It didn't work on my main system, though.

While fooling around, I broke my older system (the one where i got CUPS working) and had to reinstall Karmic. Before any updates are loaded, I now see CUPS is running as it should. The version in the vanilla install is 1.4.1-5ubuntu2. Next, I'll install all the updates and see what happens.

[Lars Ola Liavåg (l-liavag)]

After two rounds of updates and HW driver installs, still no problem with CUPS on the old machine despite not being set to run at run level S. Strange, and why doesn't it work on my main system. Hope I don't need to reinstall that too.

[Lars Ola Liavåg (l-liavag)]

Still no way to make it work on my main system but I've discovered that also vboxdrv does not start upon boot. This is definitely not a CUPS problem alone so I'm now following bug #500520 in stead plus some related threads on the Ubuntu fora.

[shafin (mahdee-jameel)]

Check this out, it solved my cups problem:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/500520/comments/8

[Fabio Marconi (fabiomarconi)]

Hello.
Is this problem present with the latest updated packages of Lucid ?
Thanks in advance
Fabio

[Fabio Marconi (fabiomarconi)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!