Skip to main content

Hudson is now a good-behaving Unix daemon

Posted by kohsuke on February 10, 2009 at 3:32 PM PST

Starting 1.281, Hudson can now launch itself as a proper Unix daemon. All you have to do is start Hudson as:

$ java -jar hudson.war --daemon

If you run this as root, it'll leave /var/run/ and record PID there. Unlike java -jar hudson.war &, this will detach the daemon from the shell properly, so it'll keep going even after you exit your shell. This is done by using akuma that I blogged earlier.

Similarly, when you run Hudson with the --logfile=/path/to/hudson.log option, stdout/stderr from Hudson are redirected to a log file. In addition, Hudson will respond to SIGALRM and reopens a log file, which makes Hudson friendlier to log rotation like logadm on Solaris or logrotate on Linux.

Related Topics >>


Problem installing on Ubuntu Jaunty (8.10)

After installing the hudson deb on Ubuntu server Jaunty 8.10, when I tried to run the init script /etc/init.d/hudson start, nothing would be printed and the server would not start. No log file was created under /var/log/hudson and no pid file was created under /var/run/hudson. I eventually discovered that if I set the hudson user's shell to /bin/bash instead of /bin/false in /etc/passwd everything works fine. Hope this saves someone else some trouble.

Yes, this is great stuff Kohsuke. But I can't get the '--daemon' option to work for me. The following script does work: nohup ${JAVA_HOME}/bin/java -Dhudson.util.ProcessTreeKiller.disable=true -jar hudson.war --httpPort=8081 > hudson.log 2>&1 When I changed to: ${JAVA_HOME}/bin/java -jar hudson.war --httpPort=8081 --logfile=/fully/qualified/path/to/hudson.log --daemon It does not work. No process is created and there is no output to the hudson.log file. This is on linux using JDK 1.5. I am running this is a non-root user after ssh login to one accoun followed by sudo -s to a different account.

I still get a lot of hits to that hudson manifest page I put up ( ) so I was going to update it to use this technique to launch. The sun docs on SMF state: "For contract and transient services, the start method should not return success until service is being provided. Note that this is true for daemons as well; daemons shouldn't fork() then exit() from their initial process, they should wait to return until startup errors have been accumulated and can be reported. Many init scripts used to start up the daemon and return immediately, counting on the fact that the serial boot took 'a while' to start dependent services. Now that dependent services are started precisely (often immediately) after your service returns successfully from its start method, imprecise semantics are not acceptable." In the past, I had recommended putting the process under "Wait" mode. In this mode, the SMF system just blocks until the java process exits. Do you think that under this new daemonized code, we can call it a proper service? Will the daemonized hudson wait until it is fully started before returning? If so, I will have to play with the timeout. Also, do you think this is still the best way to shutdown, or is there a more graceful way? BTW, This is all great stuff Kohsuke

Yes, I intend to give this feature a bit of soak time, then integrate into the debian package.

will this be integrated with the script in /etc/init.d/hudson (deb) ?

Sorry, don't know much about the jabber plugin. If you can file an RFE for that, that would be good, I think. Yes, you can run a daemon as a non-root. Since a daemon by definition detaches itself from the terminal, to get output from it, you need to redirect its output. Use the --logfile option.

Great work! I have a few questions: Is it possible to run as a daemon with a non-root user? Is there a way to get debug information during the startup? I tried to launch hudson using --daemon (as a non-root user), and no JVM process seemed to be started Thanks!

Excellent, I'll be sure to do this instead of the nohup solution we are currently using! I am slowly trying to migrate our project from CC to Hudson, although it is quite a challenge as our tests are in phpunit and Hudson does not seem friendly to showing test results from it (or anything else, for that matter). By the way, is there any way to set up a map for the Jabber plugin, of svn usernames to jabber prefixes/usernames, if they don't match up? Thanks!

Nice job, Kosuke

You need to do more work with nohup, like redirecting stdin/out/err to make sure it won't leak a descriptor (for example when you do this via ssh)

Hmm, I just added a nohup when it starts and works just fine: nohup $JAVA_HOME/bin/java -server -jar hudson.war --httpPort=35000 &