> Robie, thanks for the investigations. I have looked into what the file
/var/cache/cups/org.cups.cupsd (CUPS calls it "keepalive" file) is good
for and what CUPS does with it. The file is created by the CUPS daemon
cupsd when it needs to keep running, having active jobs, being in the
course of a reload, having the web interface active or sharing printers,
otherwise the file is removed. CUPS updates presence/no presence on
start-up and shutdown of the daemon and it does exactly the same in both
cases, so it can remain present after shutdown, depending on CUPS'
configuration. CUPS never reads this file (or checks its presence),
meaning that it is purely for advising external processes.
> So for me it looks like that there is a certain system service manager
(what one usually runs as PID 1 under Linux) which checks for the
presence of keepalive files and decides based on this which daemons to
kill and which to keep running.
Right - I believe this is launchd (under OS X).
I do not know everything about systemd. Does systemd care about
> AFAIK, no, not at all. You can configure systemd to start cupsd when a
named file appears ("systemd.path"). I can't find anything documented
about systemd stopping any service ever. The source that handles
"systemd.path" doesn't ever appear to stop a service. Upstream appears
to have configured this in their supplied systemd units, but I believe
it may be unnecessary.
> The CUPS upstream *.path makes cupsd being triggered by creating the
file, but only if the file is not there already. What is this good for?
AFAICT, it serves no purpose.
> Does this *.path also take down cupsd if one removes the keepalive
file or is systemd supposed to do so? For me cupsd does not get stopped
AFAICT, removing the file isn't supposed to cause any action. Nothing
should happen when the file is removed, and nothing does happen (apart
from perhaps some state change within systemd, or some timing delay
helping us trigger the race).
> And why does shutdown of CUPS fail after removing the keepalive file
(with "Job for cups.service canceled.")? As CUPS does not care about it,
systemd seems to depend on it.
This I'm not sure about. It may be a systemd race or bug. I pinged pitti
to take a look, but he was busy. But if we definitely don't need
cups.path, perhaps removing it will fix the problem (whether that's
working around a bug in systemd or in the current CUPS systemd
arrangements I don't know).
> And what in the prerm script of the CUPS Debian package deletes the
Nothing, AFAICT. It's only cupsd that deletes it on exit. The prerm
stops cups.path, then stops cups.service. I don't know that my example
above reproduces the root cause. But it does seem to reproduce a race
that produces the same symptoms that seems to fit reasonably well.
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
pre-removal script returned error exit status 1
To manage notifications about this bug go to:
ubuntu-bugs mailing list