Bug 800492

Jiri Dluhos
please provide YaST logs.

I assume this is related to YaST base functionality
that was changed from SysVinit to systemd recently, see
https://bugzilla.novell.com/show_bug.cgi?id=769946#c8

The YaST printer module only calls YaST Service::...
functionality which worked all the time (since openSUSE 11.1)
and the YaST printer module was not at all changed recently.

I guess this is more related to bnc#769946

A real YaST developer (i.e. someone who knows about YaST internals
in particular YaST Service::...) must analyze it - I cannot do it.

Jiri Dluhos
please provide exact error message(s) - preferably as a screen shot
so that it is more clear how you get "local cups daemon still running".
There is no matching "still running" string in the yast2-printer sources.

Created attachment 521988 [details]
Snapshot of the error message.

Sorry, the message used different wording - please see the attached screenshot.

The matching code in yast2-printer is in
/usr/share/YaST2/modules/Printerlib.ycp
excerpt (too long lines wrapped here):
-------------------------------------------------------------------------------
global boolean GetAndSetCupsdStatus( string new_status )
{ // Determine whether or not a local cupsd is accessible.
  // The value 'false' is also the right one when the command itself fails
  // (e.g. when there is no /usr/bin/lpstat binary or whatever broken stuff).
  // Since CUPS 1.4 'lpstat -r' results true even when scheduler is not running.
  // Therefore we must now grep in its output:
  string local_cupsd_accessible_commandline = "/usr/bin/lpstat -h localhost -r
| grep -q 'scheduler is running'";
...
  // Stop cupsd:
  if( "stop" == new_status )
  {
...
    // To be on the safe side try to stop and disable the cupsd
    // regardless if it is accessible or not and/or disabled or not
    // and ignore possible errors from Service::Stop and Service::Disable
    // (the local_cupsd_accessible test below should be sufficient):
    Service::Stop( "cups" );
    Service::Disable( "cups" );
    // Wait one second to make sure that cupsd has really finished
(it may do some cleanup):
    sleep( 1000 );
    local_cupsd_accessible = ExecuteBashCommand( local_cupsd_accessible_commandline );
    if( local_cupsd_accessible )
    { Popup::Error( // Popup::Error message:
                    _("A locally running CUPS daemon is still accessible.")
                  );
      return false;
    }
-------------------------------------------------------------------------------

I.e. after calling Service::Stop( "cups" ) the command
/usr/bin/lpstat -h localhost -r | grep -q 'scheduler is running'
still results 'scheduler is running'.

From my point of view this means that yast2-printer is correct
because after calling Service::Stop( "cups" ) the local cupsd
is still accessible.

From my point of view the root cause is that after calling
Service::Stop( "cups" )
the matching service is not stopped.

Frederic, please see the last three lines of comment 4. Anything you can say?

I'm guessing "Service::Stop ("cups") is only stopping cups.service, but since cups is socked activated, cups.socket is still running and it looks like still running for "outsiders"

It might be better to stop cups.socket, cups.path and cups.service at the same time.

It does not at all help to re-assign issues in core YaST
again and again to me. Read my comment#1.

Our Bugzilla's default assignee for the bug component "YaST2"
is bnc-team-screening@forge.provo.novell.com
which is the current assignee for this bug.

I wonder what the reason behind this default setting is
because there exists also yast2-maintainers@suse.de
which looks more appropriate for issues in "YaST2".

Regardless why it seems "YaST2" bugs should be assigned
to bnc-team-screening@forge.provo.novell.com
I re-assign this one now to yast2-maintainers@suse.de

Hopefully this way a real YaST developer (i.e. someone who
knows about YaST internals in particular YaST Service::...)
has time to have at least a look, see my coment#1.


Frederic Crozat,
from my point of view a I aggree to your comment#6
that the YCP call Service::Stop("foo")
should completely stop those service in all ways
how those service can be active or semi-active via systemd.

This way Service::Stop("foo") would work for systemd
in compliance how it worked all the time for SysVinit
and all YaST modules that use Service::Stop("foo")
would work the same for systemd and SysVinit.

In contrast if Service::Stop("foo") only stops foo.service
but not foo.socket, foo.path (and all other possible ways
which may exist in systemd), then Service::Stop("foo")
would be basically useless functionality for systemd
because if e.g. foo.socket is still active, any normal user
can activate the service by triggering systemd via the socket
(like "/usr/bin/lpstat -h localhost -r" does).

For individual settings of the new fine-tuning in systemd
via foo.service, foo.socket and foo.path (and all other
possible ways which may exist in systemd) there could
be new individual YCP calls especially for systemd like
Service::SystemdServiceStop("foo")
Service::SystemdSocketStop("foo")
Service::SystemdPathStop("foo")
Service::Systemd<Whatever>Stop("foo")
if there is the need in YaST to have such fine-tuning
functionality for systemd.

(In reply to comment #8)
> Service::SystemdServiceStop("foo")
> Service::SystemdSocketStop("foo")
> Service::SystemdPathStop("foo")
> Service::Systemd<Whatever>Stop("foo")
Martin, could you please figure out if function as described above make sense?

have all related problems with systemd in runlevel in one place

*** This bug has been marked as a duplicate of bug 799471 ***