Jira (PUP-8355) Debian - SysVinit/Systemd service providers - Making use of the invoke-rc.d command to know whether or not a service is enabled can lead to unexpected results

Laurent Declercq (JIRA)

unread,

Jan 16, 2018, 2:51:04 AM1/16/18

to puppe...@googlegroups.com

Laurent Declercq created an issue

PUP-8355

Debian - SysVinit/Systemd service providers - Making use of the invoke-rc.d command to know whether or not a service is enabled can lead to unexpected results

Issue Type:	Bug
Affects Versions:	PUP 5.3.3
Assignee:	Unassigned
Components:	Types and Providers
Created:	2018/01/15 11:50 PM
Environment:	Debian
Priority:	Normal
Reporter:	Laurent Declercq

Puppet Version:
Puppet Server Version:
OS Name/Version:

Describe your issue in as much detail as possible…
Describe steps to reproduce…

Desired Behavior:

Actual Behavior:

Please take a moment and attach any relevant log output and/or manifests. This will help us immensely when troubleshooting the issue.

Examples:
Run puppet agent with --test --trace --debug

Relevant sections of /var/log/puppetlabs/puppetserver/puppetserver.log or any applicable logs from the same directory.

For more detailed information turn up the server logs by upping the log level in the server's logback.xml

Relevant sections of configurations files (puppet.conf, hiera.conf, Server's conf.d, defaults/sysconfig)

For memory issues with server heap dumps are also helpful.

Add Comment

This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)

Josh Cooper (JIRA)

unread,

Jan 23, 2018, 8:16:02 PM1/23/18

to puppe...@googlegroups.com

Josh Cooper updated an issue

Puppet /

PUP-8355

Debian - SysVinit/Systemd service providers - Making use of the invoke-rc.d command to know whether or not a service is enabled can lead to unexpected results

Change By:

Josh Cooper

Acceptance Criteria:

Good morning,

I've looked your service providers for both SysVinit and Systemd (Debian). In your implementation, you make use of *invoke-rc.d* command to know whether or not a service is enabled:

# https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/debian.rb#L41
# https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/systemd.rb#L104

*Problem:* If the *policyrcd-script-zg2* package is installed, you will always get *104*, even for unknown services...

*Howto reproduce*

*1.* Behavior without the *policyrcd-script-zg2* package installed:
{code:bash}
root@stretch:~# update-rc.d apache2 defaults
root@stretch:~# update-rc.d apache2 disable
insserv: warning: current start runlevel(s) (empty) of script `apache2' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `apache2' overrides LSB defaults (0 1 6).
root@stretch:~# invoke-rc.d --quiet --query apache2 start
root@stretch:~# echo $?
101
{code}
That is the expected behavior.

*2.* Behavior with the *policyrcd-script-zg2* package installed:
{code:bash}
root@stretch:~# update-rc.d apache2 defaults
root@stretch:~# update-rc.d apache2 disable
insserv: warning: current start runlevel(s) (empty) of script `apache2' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `apache2' overrides LSB defaults (0 1 6).
root@stretch:~# invoke-rc.d --quiet --query apache2 start
root@stretch:~# echo $?
104
{code}
With dummy (inexistent) package:
{code:bash}
root@stretch:~# invoke-rc.d --quiet --query dummy start
root@stretch:~# echo $?
104
{code}
From my point of view, you should just mimic Debian behavior as done in the systemd in the Debian /lib/systemd/systemd-sysv-install script:
{code:bash}
...
is-enabled)
        # exit with 0 if $NAME is enabled, non-zero if it is disabled
        ls $ROOT/etc/rc[S5].d/S??$NAME >/dev/null 2>/dev/null
        ;;
    *)
...
{code}

Add Comment

Josh Cooper (JIRA)

unread,

Jan 23, 2018, 8:16:02 PM1/23/18

to puppe...@googlegroups.com

Josh Cooper updated an issue

Puppet /

PUP-8355

Debian - SysVinit/Systemd service providers - Making use of the invoke-rc.d command to know whether or not a service is enabled can lead to unexpected results

Change By:	Josh Cooper

Good morning,

I've looked your service providers for both SysVinit and Systemd (Debian). In your implementation, you make use of * Puppet Version: invoke-rc.d * command to know whether or not a service is enabled:
*Puppet Server Version
# https : * //github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/debian.rb#L41
*OS Name # https: / Version /github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/systemd.rb#L104

*Problem :* If the *policyrcd-script-zg2* package is installed, you will always get *104*, even for unknown services...

Describe your issue in as much detail as possible…

Describe steps to *Howto reproduce … *

* Desired 1.* Behavior : without the * policyrcd-script-zg2* package installed:

{code:bash}
root@stretch:~# update-rc.d apache2 defaults

*Actual Behavior root@stretch : * ~# update-rc.d apache2 disable

insserv: warning: current start runlevel(s) (empty) of script `apache2' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `apache2' overrides LSB defaults (0 1 6).

Please take a moment and attach any relevant log output and/or manifests root@stretch:~# invoke-rc . This will help us immensely when troubleshooting d --quiet --query apache2 start

root@stretch:~# echo $?
101
{code}

That is the issue expected behavior .

Examples *2.* Behavior with the *policyrcd-script-zg2* package installed :
Run puppet agent with {code:bash}
root@stretch:~# update - rc.d apache2 defaults
root@stretch:~# update - test rc.d apache2 disable

insserv: warning: current start runlevel(s) (empty) of script `apache2' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `apache2' overrides LSB defaults (0 1 6).

root@stretch:~# invoke - rc.d - trace - quiet - debug -query apache2 start
root@stretch:~# echo $?
Relevant sections of 104

{ code}
With dummy (inexistent) package:

{ /var/log/puppetlabs/puppetserver/puppetserver.log code:bash } } or any applicable logs from the same directory
root@stretch:~# invoke-rc . d --quiet --query dummy start
root@stretch:~# echo $?
For more detailed information turn up 104
{code}
From my point of view, you should just mimic Debian behavior as done in the server logs by upping the log level systemd in the server's logback.xml Debian /lib/systemd/systemd-sysv-install script:
{code:bash}
Relevant sections of configurations files (puppet . conf, hiera . conf .
is-enabled)
        # exit with 0 if $NAME is enabled , Server's conf non-zero if it is disabled
        ls $ROOT/etc/rc[S5] .d , defaults / sysconfig) S??$NAME >/dev/null 2>/dev/null
        ;;
For memory issues with server heap dumps are also helpful     *)
. ..
{code}