Syncronize Systemctl Status With Reality?

Home » CentOS » Syncronize Systemctl Status With Reality?
CentOS 5 Comments

The particular issue is with puppetmaster (which admittedly takes 4 minutes to actually start, setting TimeoutStartSec=300 in it’s unit file stopped the false timeout report) but I have seen it one other time (don’t remember the details). systemctl status puppetmaster
● puppetmaster.service – Puppet master Loaded: loaded (/lib/systemd/system/puppetmaster.service; enabled; vendor preset: enabled)
Active: failed (Result: resources) since Tue 2017-08-29 11:24:36 CDT; 22min ago Process: 897 ExecStart=/usr/bin/puppet master (code=exited, status=0/SUCCESS)

Aug 29 11:22:39 puppetmaster02 systemd[1]: Starting Puppet master… Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Reopening log files Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Starting Puppet master version 3.8.5
Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Could not run: Address already in use – listen(2)
Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: PID 1233 read from file /run/puppet/master.pid does not exist or is a zombie. Aug 29 11:24:36 puppetmaster02 systemd[1]: Failed to start Puppet master. Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Unit entered failed state. Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Failed with result ‘resources’. However, ps -ef | grep puppet (run just after the above) returns puppet 1380 1 0 11:26 ? 00:00:08 Passenger RubyApp: /usr/share/puppet/rack/puppetmasterd root 2015 1341 0 11:48 pts/0 00:00:00 grep –color=auto puppet Earlier ps .. also reported puppet 1355 1166 3 11:26 ? 00:00:01 Passenger AppPreloader: /usr/share/puppet/rack/puppetmasterd And, the “bottom line”, puppet agent -t on a client works. It reports finishing the catalog run and the client’s yaml files on puppetmaster are up to date. Is there a command to tell systemd to re-scan running state and update its understanding on what it finds? I tried systemctl daemon-reload just to be sure that didn’t solve the problem before posting this.

5 thoughts on - Syncronize Systemctl Status With Reality?

  • The particular issue is with puppetmaster (which admittedly takes 4 minutes to actually start, setting TimeoutStartSec=300 in it’s unit file stopped the false timeout report) but I have seen it one other time (don’t remember the details).

    systemctl status puppetmaster
    ● puppetmaster.service – Puppet master Loaded: loaded (/lib/systemd/system/puppetmaster.service; enabled; vendor preset: enabled)
    Active: failed (Result: resources) since Tue 2017-08-29 11:24:36 CDT; 22min ago Process: 897 ExecStart=/usr/bin/puppet master (code=exited, status=0/SUCCESS)

    Aug 29 11:22:39 puppetmaster02 systemd[1]: Starting Puppet master… Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Reopening log files Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Starting Puppet master version 3.8.5
    Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Could not run: Address already in use – listen(2)
    Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: PID 1233
    read from file /run/puppet/master.pid does not exist or is a zombie. Aug 29 11:24:36 puppetmaster02 systemd[1]: Failed to start Puppet master. Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Unit entered failed state. Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Failed with result ‘resources’.

    However, ps -ef | grep puppet (run just after the above) returns puppet 1380 1 0 11:26 ? 00:00:08 Passenger RubyApp: /usr/share/puppet/rack/
    puppetmasterd root 2015 1341 0 11:48 pts/0 00:00:00 grep –color=auto puppet

    Earlier ps .. also reported puppet 1355 1166 3 11:26 ? 00:00:01 Passenger AppPreloader:
    /usr/share/puppet/rack/puppetmasterd

    And, the “bottom line”, puppet agent -t on a client works. It reports finishing the catalog run and the client’s yaml files on puppetmaster are up to date.

    Is there a command to tell systemd to re-scan running state and update its understanding on what it finds? I tried systemctl daemon-reload just to be sure that didn’t solve the problem before posting this.

  • —– Original Message —–
    From: “James Hogarth”
    To: “CentOS”
    Sent: Tuesday, August 29, 2017 2:03:44 PM
    Subject: Re: [CentOS] Syncronize systemctl status with reality?

    The particular issue is with puppetmaster (which admittedly takes 4 minutes to actually start, setting TimeoutStartSec=300 in it’s unit file stopped the false timeout report) but I have seen it one other time (don’t remember the details).

    systemctl status puppetmaster
    ● puppetmaster.service – Puppet master Loaded: loaded (/lib/systemd/system/puppetmaster.service; enabled; vendor preset: enabled)
    Active: failed (Result: resources) since Tue 2017-08-29 11:24:36 CDT; 22min ago Process: 897 ExecStart=/usr/bin/puppet master (code=exited, status=0/SUCCESS)

    Aug 29 11:22:39 puppetmaster02 systemd[1]: Starting Puppet master… Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Reopening log files Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Starting Puppet master version 3.8.5
    Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Could not run: Address already in use – listen(2)
    Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: PID 1233
    read from file /run/puppet/master.pid does not exist or is a zombie. Aug 29 11:24:36 puppetmaster02 systemd[1]: Failed to start Puppet master. Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Unit entered failed state. Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Failed with result ‘resources’.

    However, ps -ef | grep puppet (run just after the above) returns puppet 1380 1 0 11:26 ? 00:00:08 Passenger RubyApp: /usr/share/puppet/rack/
    puppetmasterd root 2015 1341 0 11:48 pts/0 00:00:00 grep –color=auto puppet

    Earlier ps .. also reported puppet 1355 1166 3 11:26 ? 00:00:01 Passenger AppPreloader:
    /usr/share/puppet/rack/puppetmasterd

    And, the “bottom line”, puppet agent -t on a client works. It reports finishing the catalog run and the client’s yaml files on puppetmaster are up to date.

    Is there a command to tell systemd to re-scan running state and update its understanding on what it finds? I tried systemctl daemon-reload just to be sure that didn’t solve the problem before posting this.

  • Hmmm, that’s an interesting option, I’ll have to look into it.

    —– Original Message —

  • Note that since systemctl shows puppetmaster.service as a unit file the init script wont’ be used at all so you can ignore the file in /etc/init.d
    … that’s just there because puppetlabs are being lazy and using the same RPM on EL6 as EL7 rather than having the right files for the right subsystems on the right distribution versions … ./sigh

    Otherwise you’re down to standard troubleshooting process – use ss -tlnp to identify the process that is holding the port open, systemctl cat puppetmaster.service and see what it’s trying to do etc etc