On 29 Aug 2017 17:58, "Leroy Tennison" <leroy@xxxxxxxxxxxxxxxx> wrote:
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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
First glance ity looks like someone has started that puppetmaster manually
at some point. As such it's not in a cgroup systemd is tracking so it isn't
aware of it.
Your attempts to start the service are failing because that manually
started instance already has the port open.
Kill it with pkill -f puppet and then use ss -tnp to check for the port
being freed (wait for any time_wait states to go... which is why I'm not
filtering by listen).
Once it's clear then try starting with systemctl
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
