Issue #12146 has been updated by Daniel Pittman. Status changed from Needs More Information to Rejected
Glenn Aaldering wrote: > > So, why isn't "just don't daemonize" the right answer here? > > In Unix and other multitasking computer operating systems, a daemon is a > computer program that runs as a background process, rather than being under > the direct control of an interactive user. …but that statement isn't very connected to the "daemonizing" process, which is to fork and detach from the controlling terminal, start a new process group, etc, etc. > To me it does not make sense to manage/control the puppet 'daemon' with > upstart when it is forced to run in the foreground (which is what happens > with --no-daemonize). The ideal situation would be that the upstart init > script starts the puppet daemon the same way as the sysv init script does. I have no idea what you mean here. Upstart, like most other modern process supervision schemes, doesn't want the daemon to fork away randomly. So, tell it not to. Passing `--no-daemonize`, or setting that in the configuration file, is absolutely the right thing to do here. Adding more options, or trying to pacify the stupid heuristic in Upstart that guesses wrong, have no value. Implementing SIGSTOP to ourselves has no value to Puppet, or to anyone else. Just run Puppet without having it fork. Unless you can come back with some problem that is caused by specifying that option when run under upstart, there is nothing to be done here. ---------------------------------------- Bug #12146: Unable to implement upstart when starting puppet agent in default daemon mode https://projects.puppetlabs.com/issues/12146#change-56654 Author: Glenn Aaldering Status: Rejected Priority: Normal Assignee: Category: Target version: Affected Puppet version: 2.7.9 Keywords: upstart ubuntu sysv puppet agent daemon pid fork system programs Branch: It is currently not possible to implement an upstart script when using the puppet agent in default daemon mode. The current workaround is to start the daemon with the --no-daemonize option in the upstart script. Another solution would be to create a flag in puppet like --upstart which will make use of the SIGSTOP function. After looking at the strace it seems that when starting the puppet agent in daemon mode (this is the default starting behaviour of puppet agent) the daemon seems to 'detach' and then exec more then 20 system programs before it will spawn the final process. This is no problem with SysV since that supports pid files. Upstart though currently has no support for pid files and will try to find the pid by itself. The issue though is that upstart will only go to a maximum of 2 forks. More on this can be found here: http://upstart.ubuntu.com/cookbook/#expect After discussing with masterzen on #puppet-dev he suggested me to file a bug for this since he thought this could be caused by redmine/facter. Before puppet is actually started in 'daemon' mode the puppet agent will load providers which will call system programs. Each of these calls spawns a new pid and when all these calls are done the final process is started. Since this is more then 2 forks, upstart cannot track this PID and therefore upstart is unaware of the 'daemon'. Some examples on the system program calls: * arp * which * uname * hostname * ip * ifconfig * whoami * lsb_release * lsdev small example of a working upstart script for puppet agent: description "puppet agent" start on runlevel [2345] stop on runlevel [!2345] exec /usr/bin/puppet agent --no-daemonize small example of the failing upstart script for puppet agent: description "puppet agent" start on runlevel [2345] stop on runlevel [!2345] exec /usr/bin/puppet agent This has been tested on both Ubuntu Lucid 10.04 64bits with puppet 2.7.1 and Ubuntu 12.04 64bits with puppet 2.7.9. Using upstart for puppetmaster was not tested. -- 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 post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
