On Thu 05 Apr 2018 at 14:35:02 -0400, Stefan Monnier wrote: > Package: cups-browsed > Version: 1.20.1-1+b1 > Severity: normal > > Here's a sample session: > > # ps auxw|grep cups > root 27143 0.0 0.1 19508 9600 ? Ss Apr04 0:07 > /usr/sbin/cupsd -l > root 27144 0.0 0.1 42080 11184 ? Ssl Apr04 0:00 > /usr/sbin/cups-browsed > root 31856 0.0 0.0 5284 876 pts/5 RN+ 14:27 0:00 grep cups > ~-0# /etc/init.d/cups stop;/etc/init.d/cups start > [ ok ] Stopping cups (via systemctl): cups.service. > [ ok ] Starting cups (via systemctl): cups.service. > ~-0# ps auxw|grep cups > root 31935 0.0 0.0 17516 6932 ? Ss 14:28 0:00 > /usr/sbin/cupsd -l > root 31954 0.0 0.0 5284 796 pts/5 SN+ 14:28 0:00 grep cups > ~-0# > > As you can see before the `cups stop; cups start` both `cupsd` and `cups- > browsed` were running, whereas afterwards only `cupsd` is running.
Interactions between systemd, cups and cups-browsed are well above my pay grade but I'll try to shed some light on the behaviour. > I believe this behavior is incorrect since no part of `cups stop; cups start` > says explicitly that we want `cups-browsed` to be stopped. So either `cups Indeed. cup.service does not ask for or mandate that cups-browsed be stopped. However, cups-browsed.service has the line Requires=cups.service and it will stop itself if cupsd becomes unavailable. So it is not really anything to do with cups. cups is responsible for itself, as is cups-browsed responsible for its own management. >From the cups-filters Debian changelog: > - cups-browsed: Added "Requires=cups-service" to the cups-browsed.service > file, so that systemd keeps CUPS running while shutting down cups-browsed > on system shutdown (LP: #1579905) I think cups-browsed is seen as having no function if cupsd is not running. > stop` should not stop `cups-browsed`, or it should check if `cups-browsed` is > running and arrange to make sure a subsequent `cups start` restarts it if > applicable. I've explained why cups has no responsibility for stopping cups-browsed. What I cannot explain or argue is whether cups.service should become resonsible for (re)starting another service when that service itself decides to shut down. I observe on unstable that the commands 'cupsctl --debug-logging' and 'apt --reinstall install cups-daemon' stop cupsd and cups-browsed but cups-browsed gets restarted in both cases. (The Main PIDs change). -- Brian.