Bug 717162

Created attachment 450167 [details]
screenshot

Seems like something broke down during nis-server packages installation...

Lukas, what can be reason for

2011-09-08 19:38:30 <3> linux-i50u(16326) [YCP] SuSEFirewallServices.ycp:538 Uknown service 'nis-server'

(In reply to comment #2)
> Lukas, what can be reason for
> 
> 2011-09-08 19:38:30 <3> linux-i50u(16326) [YCP] SuSEFirewallServices.ycp:538
> Uknown service 'nis-server'

YaST NIS Server tries to open service 'nis-server' in firewall but such
service doesn't exist (anymore). Services should be defined by packages
and stored in /etc/sysconfig/SuSEfirewall2.d/services/ directory.

Such service should be defined by a NIS Server package if it exists.
See also FATE #300687.

Hm, I see, so the package ypserv should probably provide the service but does not.


Anyway, this does not seem to be a problem for the bug. I've seen some problems of package installation in the logs, were all packages ("ypbind", "ypserv") installed correctly?

It maybe ypbind just uses a different service name (filename):

From logs:

SuSEFirewallServices.ycp:539 Known services: $[ ... "service:ypserv":$[
  "broadcast_ports":[], "description":"Konfiguration für einen
  NIS-Master/Slave-Server", "ip_protocols":[], "name":"NIS-Server",
  "rpc_ports":["rpcbind", "portmap", "ypserv", "fypxfrd", "yppasswdd"],
  "tcp_ports":[], "udp_ports":[]
]]

Please, see the comment 4 for the required info

Ping

lol:  o.K on a ping I must react:)

My problems are that I am in the moment on fedora15 and not SUSE and that the I have also no valid VM here and I spend the most of my time in moment on mathematics and not informatics:

 -> As far as I remember there was no problems in system verification mode with the packages and I am sure there were no shown problems during initila installation of the packages.
A deeper look at I could not take because of the causes above.

Finally, I got to this and reproduced problem.

Well, first ypserv start fails:


Failed to issue method call: Unit ypserv.service failed to load: No such file or directory. See system logs and 'systemctl status ypserv.service' for details.

2011-11-14 12:04:41 <3> linux-cs9a.site(31311) [YCP] Service.ycp:304 Error while running initscript /sbin/service ypserv start :
$["exit":1, "stderr":"redirecting to systemctl\nFailed to issue method call: Unit ypserv.service failed to load: No such file or directory. See system logs and 'systemctl status ypserv.service' for details.\n", "stdout":""]

Than, creating ypservers map fails:

"/usr/bin/make -C /var/yp/suse.cz -f ../Makefile NOPUSH=true ypservers" gives

"stderr":"failed to send 'clear' to local ypserv: RPC: Program not registered", "stdout":"make: Entering directory `/var/yp/suse.cz'\nUpdating ypservers...\nmake: Leaving directory `/var/yp/suse.cz'

and creating database:

"/usr/bin/make -C /var/yp NOPUSH=true LOCALDOMAIN=suse.cz" prints

"stderr":
failed to send 'clear' to local ypserv: RPC: Program not registeredfailed to send 'clear' to local ypserv: RPC: Program not registeredfailed to send 'clear' to local ypserv: RPC: Program not registeredfailed to send 'clear' to local ypserv: RPC: Program not registered",

"stdout":"make: Entering directory `/var/yp'\ngmake[1]: Entering directory `/var/yp/suse.cz'\nUpdating group.byname...\nUpdating group.bygid...\nUpdating passwd.byname...\nUpdating passwd.byuid...\ngmake[1]: Leaving directory `/var/yp/suse.cz'\nmake: Leaving directory `/var/yp'\n"

Michael, what is wrong?

Is there a problem with recent switch to systemd?

I have no clue about yp. We need to ask Thorsten about this.

(In reply to comment #3)
> (In reply to comment #2)
> > Lukas, what can be reason for
> > 
> > 2011-09-08 19:38:30 <3> linux-i50u(16326) [YCP] SuSEFirewallServices.ycp:538
> > Uknown service 'nis-server'
> 
> YaST NIS Server tries to open service 'nis-server' in firewall but such
> service doesn't exist (anymore). Services should be defined by packages
> and stored in /etc/sysconfig/SuSEfirewall2.d/services/ directory.
> 
> Such service should be defined by a NIS Server package if it exists.
> See also FATE #300687.

The service name in /etc/sysconfig/SuSEfirewall2.d/services/ is "ypserv" and always was ypserv, never something else. Don't know where nis-server is coming from.

(In reply to comment #9)

> Well, first ypserv start fails:

Ok, and as long as that fails it doesn't make any sense to go further, but:

> Than, creating ypservers map fails:

No, where does it fail? Not according to the messages you posted here.

> "/usr/bin/make -C /var/yp/suse.cz -f ../Makefile NOPUSH=true ypservers" gives
> 
> "stderr":"failed to send 'clear' to local ypserv: RPC: Program not registered",
> "stdout":"make: Entering directory `/var/yp/suse.cz'\nUpdating
> ypservers...\nmake: Leaving directory `/var/yp/suse.cz'

So everything is ok.

> and creating database:

works, too.

(In reply to comment #10)
> Michael, what is wrong?
> 
> Is there a problem with recent switch to systemd?

If yes, then it is a systemd bug. systemd should work fine with LSB compatible init scripts. But I don't know anything about systemd to answer this.

(In reply to comment #13)
> (In reply to comment #9)
> 
> > Well, first ypserv start fails:
> 
> Ok, and as long as that fails it doesn't make any sense to go further, but:
> 
> > Than, creating ypservers map fails:
> 
> No, where does it fail? Not according to the messages you posted here.

Right, the command actually created what it should create, but it wrote some messages to error output which YaST is interpreting as an error. I think this is new, otherwise we'd see it earlier.

(In reply to comment #14)
> (In reply to comment #10)
> > Michael, what is wrong?
> > 
> > Is there a problem with recent switch to systemd?
> 
> If yes, then it is a systemd bug. systemd should work fine with LSB compatible
> init scripts. But I don't know anything about systemd to answer this.

Frederic, any idea?

(In reply to comment #15)
> (In reply to comment #13)
> > (In reply to comment #9)
> > 
> > > Well, first ypserv start fails:
> > 
> > Ok, and as long as that fails it doesn't make any sense to go further, but:
> > 
> > > Than, creating ypservers map fails:
> > 
> > No, where does it fail? Not according to the messages you posted here.
> 
> Right, the command actually created what it should create, but it wrote some
> messages to error output which YaST is interpreting as an error. I think this
> is new, otherwise we'd see it earlier.

No, it is not new, but you don't see them if ypserv is running.

hmm, it might be caused because nothing told systemd to reload its configuration after ypserv was installed. I guess either rpm macros for installing service or insserv should "ping" systemd to reload its configuration sometime..

So it's for service maintainer anyway?

hmm, I would probably modify insserv to cause a systemctl daemon-reload (not sure when..)

(In reply to comment #19)
> So it's for service maintainer anyway?

Sorry, don't understand your question.

(In reply to comment #21)
> (In reply to comment #19)
> > So it's for service maintainer anyway?
> 
> Sorry, don't understand your question.

In comment 18, Frederic points as one solution 'rpm macros for installing service'. That's why I asked you again as service maintainer.

(In reply to comment #20)
> hmm, I would probably modify insserv to cause a systemctl daemon-reload (not
> sure when..)

So... Werner?

Hmmm ... now I've a bug #728947 in which the daemon-reload should be suppressed
which seems not to work and with this bug I've the opposite desire for a
daemon-reload.

Now as insserv uses already systemctl this question should go to the
maintainer of systemctl as for such a support insserv strongly depends
on systemctl, that is if --no-reload is choosen or the opposite if the
option is *not* choosen this should work out of the box.

Also the question rises what are the differences of

   --no-reload
   daemon-reload
   reload [NAME...]
   load [NAME...]

let's explicit this thing a little bit :

systemd doesn't automatically reload the various .service (or initscripts) files when they change on disk, so there is a need to tell it when to refresh its configuration (ie when those files changes).

bnc#728947 is when insserv is used on a sysvinit system with systemd installed and in this case, the forward to systemd was trying to tell systemd to reload disk configuration, which fails (since systemd doesn't run) and was causing a error return code.

here, we are in a different situation : systemd is running, so /sbin/service (through /etc/rc.status) is forwarding to systemd, to make sure initscripts are correctly managed by systemd.

This means when a new package is installed, with a initscript, "something" needs to tell systemd to "reload" disk configuration.

Since insserv is "the" standard way to enable / disable initscripts in package, it would be logical it notifies systemd it should reload disk configuration (another way could be to modify the initscripts relevant macros, but in this case, it would require rebuilding all packages shipping initscripts). Currently, when systemctl enable foo.service is used (foo being an initscript), systemd correctly reload its configuration (unless --no-reload is used).

(In reply to comment #24)

OK ... as insserv never had restart any jobs/services this should be done
in the appropiate spec file macro %restart_on_update() or after changing
the configuration of a service by e.g. YaST2.

For  %restart_on_update() systemctl should know about try-restart as the
LSB script will be executed with the argument try-restart.

For normal installtion the macro %fillup_and_insserv() should be used.
As %fillup_and_insserv() uses %add_start_if_needed() and this one simply does

   /sbin/insserv ${YAST_IS_RUNNING:+-f} /etc/init.d/$SCRIPTNAME

the systemctl is only used if ypserv would have a systemd service unit file
(it does not AFAICS).

Also I see that /etc/sysconfig/SuSEfirewall2.d/services/ypserv will be 
installed by the package ypserv.

Therefore I do not see how insserv is involved on (re)starting the ypserv
script.

The question is: does the start/stop link (SysVinit) for the ypserv script
exists.  That is I'd like to see what

       ls -l /etc/init.d/*.d/*yp*

will show?

In respect that the ticket was originally filed on 11.9.2011 you surely understand that the original OS settup is gone.

So, I have made a new installation on openSUSE 12.1 final 64bit and did the steps I originally listed on the reproducing section.

1.The settup of the server(as master) works! -> the original bug is gone.

2.Anyway I´ve done what you requested:

ls -l /etc/init.d/*.d/*yp*
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc3.d/K01ypserv -> ../ypserv
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc3.d/K01ypxfrd -> ../ypxfrd
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc3.d/K04ypbind -> ../ypbind
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc3.d/S12ypserv -> ../ypserv
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc3.d/S13ypbind -> ../ypbind
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc3.d/S13ypxfrd -> ../ypxfrd
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc5.d/K01ypserv -> ../ypserv
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc5.d/K01ypxfrd -> ../ypxfrd
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc5.d/K04ypbind -> ../ypbind
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc5.d/S12ypserv -> ../ypserv
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc5.d/S13ypbind -> ../ypbind
lrwxrwxrwx 1 root root 9 26. Nov 12:58 /etc/init.d/rc5.d/S13ypxfrd -> ../ypxfrd

I attach a new round of logs for final review (if you want).

Created attachment 464169 [details]
logs- yast2,messages,warn

Created attachment 464171 [details]
yp folder in var

From my side this could be closed here.

OK ... WORKSFORME

Ahhh,...

I let it as it is, but WORKSFORM is not correct. The issue was not caused by my specific usage.

It was reproducible on MS5 and is gone with final,...why ever.

(In reply to comment #33)
> Ahhh,...
> 
> I let it as it is, but WORKSFORM is not correct. 

Indeed, I was able to reproduce it as well and the problem was that the service did not start. Just try it yourself with 12.1

IMHO insserv does its job and if this fails then systemd has a problem.

well, we can change the rpm macros to call systemd if it is running, when upgrading initscripts, but this would require changing rpm macros and rebuilding package with the updated rpm macros..

*** Bug 751778 has been marked as a duplicate of this bug. ***

rpm macro was changed in Factory, in time for 12.2. We can't change anything for 12.1 packages. Closing as fixed