Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #170802 > unrolled thread

invoke-rc.d & systemd

Started byAndre Majorel <aym-naibed@teaser.fr>
First post2016-08-07 14:50 +0200
Last post2016-08-08 11:00 +0200
Articles 9 — 5 participants

Back to article view | Back to linux.debian.user


Contents

  invoke-rc.d & systemd Andre Majorel <aym-naibed@teaser.fr> - 2016-08-07 14:50 +0200
    Re: invoke-rc.d & systemd Henrique de Moraes Holschuh <hmh@debian.org> - 2016-08-07 15:40 +0200
      Re: invoke-rc.d & systemd Andre Majorel <aym-naibed@teaser.fr> - 2016-08-07 16:20 +0200
        Re: invoke-rc.d & systemd Henrique de Moraes Holschuh <hmh@debian.org> - 2016-08-07 17:00 +0200
        Re: invoke-rc.d & systemd Jonathan Dowland <jmtd@debian.org> - 2016-08-08 11:30 +0200
    Re: invoke-rc.d & systemd Ansgar Burchardt <"Ansgar Burchardt"@43-1.org> - 2016-08-07 16:00 +0200
      Re: invoke-rc.d & systemd Henrique de Moraes Holschuh <hmh@debian.org> - 2016-08-07 17:10 +0200
        Re: invoke-rc.d & systemd Ansgar Burchardt <"Ansgar Burchardt"@43-1.org> - 2016-08-08 10:10 +0200
    Re: invoke-rc.d Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> - 2016-08-08 11:00 +0200

#170802 — invoke-rc.d & systemd

FromAndre Majorel <aym-naibed@teaser.fr>
Date2016-08-07 14:50 +0200
Subjectinvoke-rc.d & systemd
Message-ID<s3vGF-3OS-15@gated-at.bofh.it>
I'm working on a program to make changes to a daemon's
configuration file. The man page helpfully warns against doing
that without immediately restarting it.

Do you think the following would work on any Debian system,
regardless of its current run level and choice of init system ?

1. run invoke-rc.d daemon-package stop
2. update config file
3. run invoke-rc.d daemon-package start

Thanks in advance.

-- 
André Majorel <http://www.teaser.fr/~amajorel/>
Dear spammer : the email addresses in this message have been
brought to you by bugs.debian.org.

[toc] | [next] | [standalone]


#170803

FromHenrique de Moraes Holschuh <hmh@debian.org>
Date2016-08-07 15:40 +0200
Message-ID<s3wt3-4nL-29@gated-at.bofh.it>
In reply to#170802
On Sun, 07 Aug 2016, Andre Majorel wrote:
> I'm working on a program to make changes to a daemon's
> configuration file. The man page helpfully warns against doing
> that without immediately restarting it.
> 
> Do you think the following would work on any Debian system,
> regardless of its current run level and choice of init system ?
> 
> 1. run invoke-rc.d daemon-package stop
> 2. update config file
> 3. run invoke-rc.d daemon-package start

That works, but it doesn't take into account any socket activation or
other such functionality (which *is* a bug in invoke-rc.d that has not
been fixed yet).  You have to manually account for such uses and
explicitly disable them as well around the config change, at least for
now.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]


#170807

FromAndre Majorel <aym-naibed@teaser.fr>
Date2016-08-07 16:20 +0200
Message-ID<s3x5M-4So-3@gated-at.bofh.it>
In reply to#170803
On 2016-08-07 10:19 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 07 Aug 2016, Andre Majorel wrote:
>
> > 1. run invoke-rc.d daemon-package stop
> > 2. update config file
> > 3. run invoke-rc.d daemon-package start
>
> That works, but it doesn't take into account any socket activation or
> other such functionality (which *is* a bug in invoke-rc.d that has not
> been fixed yet).  You have to manually account for such uses and
> explicitly disable them as well around the config change, at least for
> now.

Thanks. Are you referring to this ?

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734766

What is a "socket activation" ? Would that by any chance be a
systemd thing to declare that you plan to listen on some port ?

-- 
André Majorel <http://www.teaser.fr/~amajorel/>
Ever heard of the Debian project publishing the email addresses
of their users ? No, they don't, they're not that lame.

[toc] | [prev] | [next] | [standalone]


#170809

FromHenrique de Moraes Holschuh <hmh@debian.org>
Date2016-08-07 17:00 +0200
Message-ID<s3xIt-56Z-7@gated-at.bofh.it>
In reply to#170807
On Sun, 07 Aug 2016, Andre Majorel wrote:
> On 2016-08-07 10:19 -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 07 Aug 2016, Andre Majorel wrote:
> > > 1. run invoke-rc.d daemon-package stop
> > > 2. update config file
> > > 3. run invoke-rc.d daemon-package start
> >
> > That works, but it doesn't take into account any socket activation or
> > other such functionality (which *is* a bug in invoke-rc.d that has not
> > been fixed yet).  You have to manually account for such uses and
> > explicitly disable them as well around the config change, at least for
> > now.
> 
> Thanks. Are you referring to this ?
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734766
> 
> What is a "socket activation" ? Would that by any chance be a
> systemd thing to declare that you plan to listen on some port ?

Yes.  And it can only happen if you have a systemd unit that enables it
explicitly (AFAIK, ending in .socket), so it should be easy to account
for.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]


#170839

FromJonathan Dowland <jmtd@debian.org>
Date2016-08-08 11:30 +0200
Message-ID<s3P2G-7YV-37@gated-at.bofh.it>
In reply to#170807

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 07, 2016 at 03:58:50PM +0200, Andre Majorel wrote:
> What is a "socket activation" ? Would that by any chance be a
> systemd thing to declare that you plan to listen on some port ?

It is also possible via various inetd solutions.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]


#170805

FromAnsgar Burchardt <"Ansgar Burchardt"@43-1.org>
Date2016-08-07 16:00 +0200
Message-ID<s3wMp-4w1-7@gated-at.bofh.it>
In reply to#170802
Andre Majorel writes:
> I'm working on a program to make changes to a daemon's
> configuration file. The man page helpfully warns against doing
> that without immediately restarting it.
>
> Do you think the following would work on any Debian system,
> regardless of its current run level and choice of init system ?
>
> 1. run invoke-rc.d daemon-package stop
> 2. update config file
> 3. run invoke-rc.d daemon-package start

That might behave different than expected when current state of the
daemon and the boot configuration differ: for example the sequence above
will start the daemon if it was not running before but is configured to
start at boot; or it will stop the daemon if it was manually started but
is not configured to start automatically at boot.

systemctl has a `try-restart` option that might be helpful in such
cases, but this is optional for LSB init scripts (yay...).  `reload`
would also work if supported.

Ansgar

[toc] | [prev] | [next] | [standalone]


#170810

FromHenrique de Moraes Holschuh <hmh@debian.org>
Date2016-08-07 17:10 +0200
Message-ID<s3xS9-5pY-15@gated-at.bofh.it>
In reply to#170805
On Sun, 07 Aug 2016, Ansgar Burchardt wrote:
> That might behave different than expected when current state of the
> daemon and the boot configuration differ: for example the sequence above

It shouldn't, unless invoke-rc.d is broken.  The whole reason it exists
is exactly to account for boot state (i.e. enabled/disabled, as opposed
to started/stopped).  Also refer to policy-rc.d, which can tell
invoke-rc.d to ignore any attempts to, e.g., start a service.
invoke-rc.d is meant to be used in "package maintainer scripts", not for
local admin or user to use.

Normal admin work is done using "service", which will do exactly what
you told it to, and doesn't even care for boot state.

> start at boot; or it will stop the daemon if it was manually started but
> is not configured to start automatically at boot.

It has to stop it, yes.  That's exactly the point, since it is meant to
be used during daemon upgrades.  We *usually* don't want a daemon
running while its components and configuration are being updated under
its feet, unless it is a daemon engineered to tolerate it well (which is
actually easy to do on simple daemons, so it is actually the rule rather
than the exception).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]


#170833

FromAnsgar Burchardt <"Ansgar Burchardt"@43-1.org>
Date2016-08-08 10:10 +0200
Message-ID<s3NNg-7fc-33@gated-at.bofh.it>
In reply to#170810
Henrique de Moraes Holschuh writes:
> On Sun, 07 Aug 2016, Ansgar Burchardt wrote:
>> That might behave different than expected when current state of the
>> daemon and the boot configuration differ: for example the sequence above
>
> It shouldn't, unless invoke-rc.d is broken.

It does as you say yourself:

> The whole reason it exists
> is exactly to account for boot state (i.e. enabled/disabled, as opposed
> to started/stopped).

But if you want to restart a running daemon, that action does *not*
depend on the boot configuration at all: it should be restarted if
running, but not started if it was not running before.  invoke-rc.d
doesn't help in this case.

>> start at boot; or it will stop the daemon if it was manually started but
>> is not configured to start automatically at boot.
>
> It has to stop it, yes.  That's exactly the point, since it is meant to
> be used during daemon upgrades.  We *usually* don't want a daemon
> running while its components and configuration are being updated under
> its feet, unless it is a daemon engineered to tolerate it well (which is
> actually easy to do on simple daemons, so it is actually the rule rather
> than the exception).

Well, the default for packages using debhelper has recently changed:

+---
| v10 This compatibility level is open for beta testing; changes may
| occur.
|
| Changes from v9 are:
| [...]
| - The dh_installinit command now defaults to --restart-after-upgrade.
|   For packages needing the previous behaviour, please use
|   --no-restart-after-upgrade.
+---[ man:debhelper(5) ]

So the default assumption for Debian is to expect this to work.

Changing the configuration and only then restarting the service also
matches what happens with most configuration changes besides packages
upgrades in my experience (either manual changes or changes applied by a
configuration management system).

Ansgar

[toc] | [prev] | [next] | [standalone]


#170835 — Re: invoke-rc.d

FromJonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com>
Date2016-08-08 11:00 +0200
SubjectRe: invoke-rc.d
Message-ID<s3OzD-7xb-15@gated-at.bofh.it>
In reply to#170802
André Majorel:
> Do you think the following would work on any Debian system, regardless 
> of its current run level and choice of init system ?
>
> 1. run invoke-rc.d daemon-package stop
> 2. update config file
> 3. run invoke-rc.d daemon-package start 

Don't use invoke-rc.d yourself.  The *old pre-systemd* Debian Policy 
Manual vaguely and indirectly warns against it; my proposed revised 
systemd-aware Debian Policy Manual explicitly warns against it, based 
upon discussions during the Debian systemd Hoo-Hah; the manual page for 
my invoke-rc.d shim warns against it; even the Debian/Ubuntu manual page 
indirectly explains what it is not for. It is for a very particular 
need.  It is not for general service management tasks by a system 
administrator.  Use the "service" command.

* https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
* https://jdebp.eu./Proposals/DebianPolicy/ch-opersys.html#s-sysvrc
* 
https://jdebp.eu./Proposals/DebianPolicy/ch-opersys.html#s-systemdandupstartandrc
* https://jdebp.eu./Proposals/DebianPolicy/ch-opersys.html#s9.3.1.2
* https://jdebp.eu./Softwares/nosh/guide/invoke-rc.d.html
* http://manpages.ubuntu.com./manpages/xenial/man8/invoke-rc.d.8.html

Don't use "stop" followed by "start" to enact a conditional restart 
after reconfiguration.  That unilaterally starts services if they 
weren't already running.  Use a single invocation with the verb 
"force-reload".  You can often also use "try-restart", or 
"condrestart".  The latter two are better, as a matter of fact, because 
Fedora defines "force-reload" differently to the LSB.  In the Fedora 
world, "force-reload" is supposed to actually start a service if it 
isn't currently running.

* 
https://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782993
* 
https://fedoraproject.org/w/index.php?title=Packaging:SysVInitScript&oldid=297366#Required_Actions

My shims are not the only places where verb translation happens. You 
have to do it, too, if you move between "invoke-rc.d"/"service" and 
other things.  systemd's own systemctl utility is not the same as the 
"service" command, for one thing.  It does not provide the LSB verb set, 
but a revised verb set of its own; one that has changed with time, too.  
For it, the (currently) correct verb here is "try-reload-or-restart", 
which attempts a reload, and if that is not possible does a restart, but 
only if the service is currently already running.  "condrestart" used to 
be available and documented as an alias for (what was then) the 
"reload-or-try-restart" verb, and later became an alias for the 
"try-restart" verb.  It has since been removed from the systemctl 
documentation altogether.  I haven't checked whether it is still 
actually there in the program.

* 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Services.html#tabl-Managing_Services_with_systemd-Services-systemctl
* 
https://lists.freedesktop.org/archives/systemd-devel/2010-September/000387.html
* 
https://lists.freedesktop.org/archives/systemd-devel/2010-November/000863.html
* https://bugzilla.redhat.com/show_bug.cgi?id=635780
* http://linuxmanpages.net/manpages/fedora16/man1/systemctl.1.html

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web