Created attachment 231578 [details] [PATCH] Only output when it is a terminal. This prevents puppet7's rcvar test choking on it Puppet7 uses service $svcname rcvar to check whether it is enabled. The unpatched uwsgi rc.d script adds some verbose information that confuses this check $ service uwsgi rcvar Processing uwsgi profile: puppetboard # uwsgi # uwsgi_enable="YES" # (default: "") The patch attached prevents verbose echo’ing if there is no terminal $ service uwsgi rcvar < /dev/null | cat # uwsgi # uwsgi_enable="YES" # (default: "") With a terminal, old behaviour $ service uwsgi rcvar Processing uwsgi profile: puppetboard # uwsgi # uwsgi_enable="YES" # (default: "")
Thank you for the report and patch Ruben. Is it possible this can be resolved in puppet7's rc?
(In reply to Kubilay Kocak from comment #1) It is not the puppet agent’s rc.d file, it happens when “ensuring” a service in puppet. Of course I could also write a patch to harden their rcvar check handling. It currently doesn’t expect anything else than the rcvar value or comments. sudo puppet apply -e 'service{ "uwsgi": enable=>false, ensure=>"stopped"}' Notice: Compiled catalog for helium.niet.verweg.com in environment production in 0.01 seconds Error: /Stage[main]/Main/Service[uwsgi]: Could not evaluate: rcvar value is empty Notice: Applied catalog in 0.06 seconds sudo puppet apply —debug -e 'service{ "uwsgi": enable=>false, ensure=>"stopped"}' … Debug: Facter: fact "operatingsystem" has resolved to: FreeBSD Debug: Service[uwsgi](provider=freebsd): Could not find uwsgi in /etc/rc.d Debug: Executing: '/usr/local/etc/rc.d/uwsgi onestatus' Debug: Executing: '/usr/local/etc/rc.d/uwsgi rcvar' Error: /Service[uwsgi]: Could not evaluate: rcvar value is empty Debug: Class[Main]: Resource is being skipped, unscheduling all events Debug: Stage[main]: Resource is being skipped, unscheduling all events …
Hey! Seeing this while on vacation. FYI I started to look at adding support for profiles in services a while ago here: https://github.com/puppetlabs/puppet/pull/8607 Other things with higher priority came, but this is still something I think is interesting to have. If you have some spare time for this, feel free to catch on with this and ping me (@smortex on GitHub) so that I can follow this and help if I can when I I back from holiday. AFAIC, minor adjustments to the ports tree to have all services with profile output the same type of information will be needed at some point, but I do not consider this as a blocker given that improving consistency is always a move in the right direction! Thanks!
Hi, Thanks Romain! Going through (PUP-2153) Add support for FreeBSD profiles #8607 and a look at e.g. service dnsdist rcvar I see that the patch for uwsgi’s rc.d script might be incomplete. Maybe it should be changed to “ ==> XXX profile:” and continue the work in PUP-2153 with eventually having all this profile handling ending up in rc.subr to keep things consistent in the future.
There is also another issue due to the “exit 0” that is emitted while iterating through all profiles. This prevents process management tools failures in uwsgi profile startup. The least it should be set to “exit $?”. Better to remember any failed start and return that instead
how does FreeBSD's own service enable foo deal with this?