[opensuse] systemctl enable chokes on nfs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, look: minas-tirith:~ # chkconfig nfs nfs off minas-tirith:~ # systemctl enable nfs.service nfs.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig nfs on The unit files have no [Install] section. They are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). minas-tirith:~ # systemctl status nfs.service nfs.service - LSB: NFS client services Loaded: loaded (/etc/init.d/nfs) Drop-In: /run/systemd/generator/nfs.service.d └─50-insserv.conf-$remote_fs.conf Active: inactive (dead) since Fri 2014-08-01 19:14:28 CEST; 29s ago Aug 01 12:36:42 minas-tirith.valinor systemd[1]: Starting LSB: NFS client services... Aug 01 12:36:42 minas-tirith.valinor sm-notify[23684]: Version 1.2.8 starting Aug 01 12:36:42 minas-tirith.valinor nfs[23677]: Not starting NFS client services - no NFS found in /etc/fstab:..unused Aug 01 12:36:42 minas-tirith.valinor systemd[1]: Started LSB: NFS client services. Aug 01 19:14:28 minas-tirith.valinor systemd[1]: Stopping LSB: NFS client services... Aug 01 19:14:28 minas-tirith.valinor nfs[31263]: Shutting down NFS client services:..done Aug 01 19:14:28 minas-tirith.valinor systemd[1]: Stopped LSB: NFS client services. minas-tirith:~ # chkconfig nfs nfs on minas-tirith:~ # As you can see, despite the verbose complain by systemctl, the service is enabled - but I have to find out from chkconfig, because "systemctl status" doesn't say it is. Or I don't see it. What is that "install" section, what should it have to silence the complains? - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPbzCwACgkQja8UbcUWM1zh6AD+OHlZs0uFTGnEoIC9yx3+KiLo SbLd7IQiz4w6XD6sKxMA/34R80YqJIyB8CgY0bcDjxKSIJUnajZAWZIXwJG/Tc1z =yj3k -----END PGP SIGNATURE-----
On 08/01/2014 12:19 PM, Carlos E. R. wrote: <Sorry Carlos - you get 2 copies, forgot to change the address>
minas-tirith:~ # systemctl enable nfs.service nfs.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig nfs on
Here there looks to be a bit of confusion between systemd and /etc/init.d. Calling *systemctl enable nfs.service* generally just *enables* the service to start as part of a systemd target -- it doesn't necessarily mean the same as start (i.e. systemctl start nfs). Where there is a bit of disconnect is since there is no systemd nfs.service, it is checking /etc/init.d/nfs and as it says calling *chkconfig nfs on* which in the init.d world does generally mean *start* it too. I don't know why in nfs case you get the [Install] section verbiage, but the log makes sense in that systemd has done its job, it called chkconfig, so it's done with its part and is shutting down. Once it passed off responsibility to sysvinit, it looks like it expects you to follow up there for further information/status on nfs. Of course you can still expect log events to be passed to journalctl, so you could look there for expected nfs entries. This is my understanding of how the compatibility mode works (in summary). My understanding is far from complete, so others will have to chime in and add/correct as needed. But to me, it looks like systemctl did what it was supposed to, handed nfs off to chkconfig, then said it was done with nfs and showed shutting down the systemd nfs launch process. I would still expect nfs to be *on* in chkconfig, and if it was successfully started by *chkconfig nfs on*, then I would expect it to be running. <snip>
minas-tirith:~ # chkconfig nfs nfs on minas-tirith:~ #
That's what I would expect.
As you can see, despite the verbose complain by systemctl, the service is enabled - but I have to find out from chkconfig, because "systemctl status" doesn't say it is. Or I don't see it.
What is that "install" section, what should it have to silence the complains?
I think there is something in the response systemctl is getting from */usr/sbin/chkconfig nfs on* isn't what it needs which is causing it to complain. Other than the response, it looks like it is doing what it should. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: <alpine.LSU.2.11.1408012331490.25240@minas-tirith.valinor> El 2014-08-01 a las 14:14 -0500, David C. Rankin escribió:
On 08/01/2014 12:19 PM, Carlos E. R. wrote:
<Sorry Carlos - you get 2 copies, forgot to change the address>
Don't worry :-)
minas-tirith:~ # systemctl enable nfs.service nfs.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig nfs on
Here there looks to be a bit of confusion between systemd and /etc/init.d. Calling *systemctl enable nfs.service* generally just *enables* the service to start as part of a systemd target -- it doesn't necessarily mean the same as start (i.e. systemctl start nfs).
No confussion, I just wanted to "enable" it, not "start" it, for the moment at least.
Where there is a bit of disconnect is since there is no systemd nfs.service, it is checking /etc/init.d/nfs and as it says calling *chkconfig nfs on* which in the init.d world does generally mean *start* it too.
No, no, chkconfig does not start services automatically: minas-tirith:~ # rcnfs stop redirecting to systemctl stop nfs.service minas-tirith:~ # chkconfig nfs nfs off minas-tirith:~ # chkconfig nfs on minas-tirith:~ # rcnfs status Checking for mounted nfs shares (from /etc/fstab):gssd not running idmapd not running unused nfs.service - LSB: NFS client services Loaded: loaded (/etc/init.d/nfs) Drop-In: /run/systemd/generator/nfs.service.d └─50-insserv.conf-$remote_fs.conf Active: inactive (dead) since Fri 2014-08-01 19:14:28 CEST; 4h 10min ago minas-tirith:~ # minas-tirith:~ # rcnfs start redirecting to systemctl start nfs.service minas-tirith:~ # rcnfs status Checking for mounted nfs shares (from /etc/fstab):gssd not running idmapd not running unused nfs.service - LSB: NFS client services Loaded: loaded (/etc/init.d/nfs) Drop-In: /run/systemd/generator/nfs.service.d └─50-insserv.conf-$remote_fs.conf Active: active (exited) since Fri 2014-08-01 23:26:07 CEST; 1s ago Process: 1708 ExecStart=/etc/init.d/nfs start (code=exited, status=6) minas-tirith:~ #
I don't know why in nfs case you get the [Install] section verbiage, but the log makes sense in that systemd has done its job, it called chkconfig, so it's done with its part and is shutting down. Once it passed off responsibility to sysvinit, it looks like it expects you to follow up there for further information/status on nfs. Of course you can still expect log events to be passed to journalctl, so you could look there for expected nfs entries.
This is my understanding of how the compatibility mode works (in summary). My understanding is far from complete, so others will have to chime in and add/correct as needed. But to me, it looks like systemctl did what it was supposed to, handed nfs off to chkconfig, then said it was done with nfs and showed shutting down the systemd nfs launch process. I would still expect nfs to be *on* in chkconfig, and if it was successfully started by *chkconfig nfs on*, then I would expect it to be running.
Well, I do not expect the "install" verbiage, and I understand that it means that there is a syntax error in that init file. And I expect, however the service is enabled, to clearly say so - because that verbiage seems to indicate that there was an error and the service was not enabled, when it was, infact.
I think there is something in the response systemctl is getting from */usr/sbin/chkconfig nfs on* isn't what it needs which is causing it to complain. Other than the response, it looks like it is doing what it should.
Posibly. - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPcB8UACgkQja8UbcUWM1xptwD8C13WTxMx8+o+IfDDsfQj6djp ADVyJqy/ot3gUuO2M5kA/A2DcZvUOGK3Qm/yZi6IeZ34xv1E9W6GqEnI7y1cVoGD =KdvV -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Fri, 1 Aug 2014 19:19:32 +0200 (CEST) "Carlos E. R." <carlos.e.r@opensuse.org> пишет:
As you can see, despite the verbose complain by systemctl, the service is enabled - but I have to find out from chkconfig, because "systemctl status" doesn't say it is.
"systemctl status" shows unit state as known by systemd; and systemd has no information about chkconfig state. It may be possible to make sytemctl check whether unit is legacy initscript and do some additional magic; any takers?
What is that "install" section, what should it have to silence the complains?
It is a bug in systemctl - it should stop when file is found to be legacy script. It is fixed upstream and fix is trivial two-liner. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlPcZm4ACgkQR6LMutpd94wYhACgmoBoAGmRiXSwHgk348PjrEpI o50AoLnCIJ7HtaArPNy8SZRoahH2OPQY =XK8O -----END PGP SIGNATURE-----
participants (4)
-
Andrey Borzenkov -
Carlos E. R. -
Carlos E. R. -
David C. Rankin