[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#894984: cups-browsed: Stopping and starting `cups` ends up stopping `cups-browsed`



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.


Reply to: