Issue #12146 has been updated by Glenn Aaldering.
Daniel Pittman wrote: > I thought the general strategy for upstart was that the daemon wouldn't fork > itself, no? In which case using the option to tell it not to seems like the > most reasonable choice to me. Is there a reason you don't want to go down > that path, or am I misunderstanding something? Not sure but seems that you are misunderstanding something. Did you check the link that is in the issue? That would explain a lot probably. Also to clarify things ill give 2 examples: --no-daemonize: when using the --no-daemonize flag of puppet agent (/usr/bin/puppet agent --no-daemonize) in the upstart script everything works as expected. Upstart will start puppet agent. Puppet agent keep its starting PID. Example: using "start puppet" will spawn pid 1000. Puppet agent runs with pid 1000. --daemonize: when using the default deamonized function of puppet agent (/usr/bin/puppet agent) the upstart script will fail. Upstart will start puppet agent. Puppet agent will fork 20+ system programs and then actually start the daemon itself. Example: using "start puppet" will spawn pid 1000. That process forks about 20 system programs. After thats done puppet agent will run on pid 1021. If the final pid would be 1002 or if puppet sends a sigstop i think we could use expect for the daemonized mode of puppet agent in upstart. > It would also help if you could point to official documentation about what > upstart wants processes to do, so that if we add support we can do it > properly. http://upstart.ubuntu.com/cookbook/ ---------------------------------------- Bug #12146: Unable to implement upstart when starting puppet agent in default daemon mode https://projects.puppetlabs.com/issues/12146 Author: Glenn Aaldering Status: Needs More Information 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.
