Jira (PUP-10658) Puppet service ps parsing using too loose regex

15 views
Skip to first unread message

Tim Meusel (Jira)

unread,
Sep 4, 2020, 6:05:04 AM9/4/20
to puppe...@googlegroups.com
Tim Meusel created an issue
 
Puppet / Bug PUP-10658
Puppet service ps parsing using too loose regex
Issue Type: Bug Bug
Assignee: Unassigned
Created: 2020/09/04 3:04 AM
Priority: Normal Normal
Reporter: Tim Meusel

Puppet Version: 6.18.0
Puppet Server Version: 6.12.0
OS Name/Version: CentOS 6

Hello, I've got two services running, bird and bird6. their processes are also named bird and bird6. If I manage the service via puppet and set hasstatus to false, puppet will parse ps -ef: https://github.com/puppetlabs/puppet/blob/main/lib/puppet/provider/service/base.rb#L37

If I want to manage the bird service and it's currently not running, but bird6 is running, but will assume that the bird6 process relates to the bird service:

from the debug output:

Debug: Service[bird](provider=redhat): Executing 'ps -ef'
Debug: Executing: 'ps -ef'
Debug: Service[bird](provider=redhat): Process matched: bird6      10046       1  0 Aug28 ?        00:16:23 /usr/sbin/bird6 -u bird6 -g bird6

Desired Behavior:

I would like to see that the regex won't match, puppet detects the service as off and starts it

Actual Behavior:

puppet assumes that the bird service is running and won't start it

testcode

  • install bird and bird6 from epel on centos 6
  • stop bird
  • start bird6

service { 'bird':
  ensure => 'running',
  enable => true,
  hasstatus => false,
}

I know that birds init script has a status command, but using that would be a workaround for the bug and won't fix the regex in puppet

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo

Josh Cooper (Jira)

unread,
Sep 4, 2020, 11:47:03 AM9/4/20
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
Team: Night's Watch

Mihai Buzgau (Jira)

unread,
Sep 8, 2020, 10:54:05 AM9/8/20
to puppe...@googlegroups.com

Mihai Buzgau (Jira)

unread,
Sep 9, 2020, 4:39:03 AM9/9/20
to puppe...@googlegroups.com

Mihai Buzgau (Jira)

unread,
Sep 9, 2020, 4:40:04 AM9/9/20
to puppe...@googlegroups.com
Mihai Buzgau updated an issue
Change By: Mihai Buzgau
Sprint: PR NW - Triage 2020-09-16

Dorin Pleava (Jira)

unread,
Sep 15, 2020, 4:59:04 AM9/15/20
to puppe...@googlegroups.com

Mihai Buzgau (Jira)

unread,
Sep 16, 2020, 5:57:04 AM9/16/20
to puppe...@googlegroups.com
Mihai Buzgau updated an issue
Change By: Mihai Buzgau
Sprint: NW - 2020-09-16 , NW - 2020-09-30

Dorin Pleava (Jira)

unread,
Sep 16, 2020, 7:45:04 AM9/16/20
to puppe...@googlegroups.com
Dorin Pleava commented on Bug PUP-10658
 
Re: Puppet service ps parsing using too loose regex

Hi Tim Meusel,

Indeed the regex seems a bit loose, but changing the ensure regex to have an exact match may have breaking changes.

I recommend using the pattern attribute, where you can place an exact regex to match the 'ps -ef' result, like:

service

{ 'bird':   ensure => 'running',   enable => true,   hasstatus => false,   pattern => '*bird/s*' }

Tim Meusel (Jira)

unread,
Sep 16, 2020, 7:57:04 AM9/16/20
to puppe...@googlegroups.com
Tim Meusel commented on Bug PUP-10658

I agree that this might break existing setups that worked by accident. I was hoping this will be fixed for Puppet 7.

Gabriel Nagy (Jira)

unread,
Sep 24, 2020, 9:48:04 AM9/24/20
to puppe...@googlegroups.com
Gabriel Nagy commented on Bug PUP-10658

Hi Tim Meusel,

I investigated this issue a bit more and I was in favor of it initially.
However, I think it's a bit of a grey area. The code involving getpid is quite primitive, and the fix is not as simple as enclosing the service name between ^ and $.

Since we're parsing the output of ps -ef, processes can show up in a variety of ways. Here are some EL 6 examples:

Service: abrtd
ps output:
root 6509 1 0 09:35 ? 00:00:00 /usr/sbin/abrtd

Service: syslog
ps output:
root 1671 1 0 09:35 ? 00:00:00 /sbin/rsyslogd -i /var/run/syslogd.pid -c 5

Service: rpcbind
ps output:
rpc 1723 1 0 09:35 ? 00:00:00 rpcbind

I think messing with the check by trying to more closely match the process name could open up a whole can of worms (some processes have arguments, others run under an absolute path). I agree that the current behavior is a bit counterintuitive, but it does work the way it's documented:

As a last resort, Puppet will attempt to search the process table by calling whatever command is listed in the `ps` fact. The default search pattern is the name of the service, but you can specify it with the `pattern` attribute.

https://puppet.com/docs/puppet/6.18/types/service.html#service-description

Reply all
Reply to author
Forward
0 new messages