Issue #19863 has been updated by eric sorenson. Status changed from Needs Decision to Needs More Information Assignee changed from eric sorenson to Diego Elio Pettenò
The problem of the UID changing threatens to reopen #7316. I agree with Dustin, we should just stop/start and remove support for HUP in the standalone master. Diego, I notice that the init script in the Puppet distribution does not implement restart with a HUP signal; does the package you're using differ from https://github.com/puppetlabs/puppet/blob/stable/ext/gentoo/init.d/puppetmaster ? I’ve put this ticket’s status into “Needs more Information” and assigned it to you. Please either (a) update it with the information I’ve requested and re-assign it to me if you need more help, or (b) change the status to “Closed” if you were able to resolve the issue on your own. ---------------------------------------- Bug #19863: SIGHUP does not correctly restart standalone puppet master https://projects.puppetlabs.com/issues/19863#change-94607 * Author: Diego Elio Pettenò * Status: Needs More Information * Priority: Normal * Assignee: Diego Elio Pettenò * Category: * Target version: * Affected Puppet version: 3.1.1 * Keywords: * Branch: ---------------------------------------- Hello, I'm a Gentoo Linux developer and I found this bug due to the way the init script for puppet is implemented in our distribution's package. First of all, please correct me if I'm wrong in the assumption that this is the correct behaviour for a system-level puppet master: the master process is started by root; it drops privileges to the puppet user, and then keeps running; the libdir used is /var/lib/puppet. If the process is started by non-root, a non-system instance is running, and the libdir is ~/.puppet. This being the case, when the SIGHUP signal is sent to a system instance (running as puppet), it tries to re-start the master process as a non-root user, causing it to look into ~/.puppet instead of /var/lib/puppet. Furthermore, since the environment is not cleared before dropping privileges, ENV['HOME'] is still set to "/root", causing it to look for /root/.puppet (and thus failing). Unless we're doing something very wrong in Gentoo, the SIGHUP handling is unreliable for system instances (which tend to be the ones where you want to use SIGHUP). -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
