Reported by Francis Russell, Apr 11, 2011
I've observed this issue when debugging with Debian, but I believe it applies to all Unix-like distributions. When starting the monotone server, there needs to be a way to signal this to the startup script. The preferred way is (apparently) that the server process does its own forking of the child, and the started process terminates with an exit code that signifies if the daemon was started successfully. Alternatively, if the demon process does not fork. The process that starts to daemon will need to take responsibility for the backgrounding, and a failure to start can be detected by the lack of a pid-file. As far as I can tell, monotone does not support backgrounding for "mtn serve", and creates a pid-file even when the server fails to start properly. Having mtn serve return an exit code when it can't start isn't helpful since the startup script should only block for as long as is needed to know if the daemon has started correctly.
Comment 1 by Francis Russell, Apr 11, 2011
Actually, it doesn't look like Debian's start-stop-daemon will complain about a lack of a PID file either. Presumably it only uses it to stop the daemon.
Comment 2 by Richard Levitte, Apr 21, 2011
Either way, I've also always wondered why the server part doesn't signal failure... usher checks the first line it sends on stderr, which is really quite silly... It might be time to have a closer look at this.