Created attachment 202712 [details] log FreeBSD puppetserver 11.2-RELEASE-p9 FreeBSD 11.2-RELEASE-p9 #0: Tue Feb 5 15:30:36 UTC 2019 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 the puppetserver service doesn't start at boot on bare metal, I've attached the puppet log
I start to wonder what's the status of puppetserver on FreeBSD, 12.0 is not supported and the service doesn't start on 11.2. any hint?
Hi, apologies for the slow response here. I can look at your log file shortly. I can confirm that puppetserver6 does indeed run well on FreeBSD 11. I've been running puppetserver in a jail for the last several years. The 12 bug is known, but otherwise 11 should be complete functional.
I'm not sure about the file descriptor issue in your logs. I've just built and tested the HEAD version in the tree with poudriere and can confirm that the service does indeed start in an 11.2-RELEASE-p9 jail. For comparison: https://gist.github.com/xaque208/8b9049239fba0db440cedb29ea0f4930
I'm currently building and testing with a fresh jail, fresh ports, default options, etc. Will report back.
(In reply to Zach Leslie from comment #4) the service works fine in a jail but not a bare metal (with bhyve for example) and I don't want to run a jail just to start a service...
Just to be clear, have you tried it on bare metal outside of a VM? I wouldn't personally consider a VM, bhyve or otherwise, bare metal simply because of the hypervisor in the middle thats presenting the guest with the virtualized hardware. I don't currently have a host outside of a jail to test this on, but I could try a bhyve VM if that's what you're using to reproduce this issue. Just trying to narrow in on this either being an issue with bhyve or hardware. It seems odd to me that this issue would not show up in a jail but would on hardware.
(In reply to Zach Leslie from comment #6) It happens on real hw, vmware, bhyve. puppetserver5/puppetserver6, quarterly/latest branches are affected.
it starts with this patch: --- /var/cache/pkg/usr/local/etc/rc.d/puppetserver 2019-03-05 16:25:07.000000000 +0100 +++ /usr/local/etc/rc.d/puppetserver 2019-03-15 13:08:45.707056000 +0100 @@ -55,7 +55,7 @@ pidfile="/var/run/puppetserver/puppetser command="/usr/sbin/daemon" java_cmd="${puppetserver_java_home}/bin/java" procname="${java_cmd}" -command_args="-p ${pidfile} ${java_cmd} -cp /usr/local/share/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main ${puppetserver_args}" +command_args="-f -p ${pidfile} ${java_cmd} -cp /usr/local/share/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main ${puppetserver_args}" required_files="${java_cmd}"
Interesting. Can you explain why redirecting stdout helps? I'm not clear why this would change the behavior on hardware.
(In reply to Zach Leslie from comment #9) no idea, and I don't have time or motivation to debug this further.
Yeah, the "Bad file descriptor - 0" let imagine that stdin is not open (closing stdin/out/err makes sense for a service, looks like that is not what puppetserver does, but since it's running on Java I am not surprised Java does not do this by default). I guess guess I also hit this but I also had another problem related to the way I configured sudo that really goes into the same direction: depending on the way I was starting the process through sudo, sudo was willing to record puppetserver output and the service failed to start. I can't find a backtrace of that problem but I would not be surprised that the problem was similar. I am not running puppetserver on this hardware nowadays due to the update to FreeBSD 12 (I setup a 11.2 jail to run puppetserver and the problem does not appear). I do think that closing (or at least connecting /dev/null) stdin, stdout and stderr is a good move: services are supposed _not_ to use these. So +1 for adding a `-f` to the daemon(8) invocation.
Ah yes, I remember that. Great. I'll pick this up over the weekend for all the related ports.
https://reviews.freebsd.org/D19610 I've put up a review for this change.
A commit references this bug: Author: zleslie Date: Sun Mar 17 16:38:24 UTC 2019 New revision: 496072 URL: https://svnweb.freebsd.org/changeset/ports/496072 Log: Add -f to puppetserver daemon call Without this in place, the rc script does not successfully start the puppetserver service on hardware or virtualized systems, leaving jails as the only functional way to run puppetserver. PR: 236389 Reviewed by: mat(mentor) Approved by: mat(mentor) Differential Revision: D19610 Changes: head/sysutils/puppetserver5/Makefile head/sysutils/puppetserver5/files/puppetserver.in head/sysutils/puppetserver6/Makefile head/sysutils/puppetserver6/files/puppetserver.in
Thank you for reporting this issue, Mikael. The patch you suggested has been committed. Let us know if you see anything else that needs addressing.