How to ensure single daemon process?

[tkellogg]

Right now there are some safeguards to ensure that only a single daemon process is running.

Consequences of multiple daemons:

• Possible Git race condition on creating multiple commits
• Race conditions during logging
• Possible incomplete (corrupted) reads of the runtime database

Right now, we read the runtime database file at the beginning of each loop iteration. If the pid does not equal the current process' ID, then the process kills itself.

Please comment if you think this algorithm is inadequate.

[bjorn3]

I think there is a race condition where two daemons could be started at the same time, read the config file notice that the pid field is notbset and then write to the same repo. Also if the daemon crashes it will leave the pid field set in he config.

The daemon could create a unix socket in the $XDG_RUNTIME_DIR dir. If the socket already exists and is bound to this means another daemon exists and the current process should exit. Else the current process can bind to the socket. Other processed could then connect to the socket to send new repos to watch or perform other commands (maybe you could have a shutdown command or a command to list all currently watched repos) The $XDG_RUNTIME_DIR dir is removed when you log out. With this schema there is no need for any processes but the daemon to read or write the config file and any crashes will result in an unbound socket.

[tkellogg]

@bjorn3 I like this approach. It's clean. Why not use TCP sockets? that way it would work on Windows too.

Does it require any elevated permissions to listen to a socket on localhost? On any OS that you're aware of

[bjorn3]

A TCP socket only works when there is a single user on the local machine. It requires picking a port that isn't used by any other service. It may get blocked by a firewall (On windows you get a popup the first time it runs AFAIK. I'm not sure if you need admin permission to allow it.) And it may show up in port scans done by websites yoy visit like for example ebay is known to do.

TCP sockets may be a fine alternative when unix domain sockets are unavailable, but I think unix domain sockets are better for things like this. OS portability is not a big deal. Even windows 10 now supports them (not sure if libstd already exposes them on windows. if not you can use winapi)

[tkellogg]

@bjorn3 Another example where this is important is tests. Right now I have a thread::sleep to wait for the server starts. However, in the tests example I can read lines from stdout until I get a certain message (haven't done that yet). It works there because it's a child process. We could probably do the same thing via sockets.

Regarding sockets — my bias is toward going full-fledged HTTP, because you always seem to want more out of stuff like this. Like:

• GET /status — health checks, basic stats
• DELETE /status — kill current poller
• GET /last_commit — get the log entry for the last job
• GET /next_commit?wait=10 — wait up to 10 seconds for the next commit

I suppose compatibility with other tools (e.g. cURL) isn't terribly important since we can easily control the client side also. Is there a good RPC crate for unix sockets?

[bjorn3]

If you use http please make sure to check that the Origin header doesn't point to a website to prevent a security hole.