# Where to put daemon files?



## ralphbsz (Jul 31, 2014)

I'm developing a daemon (which is not intended for anyone else to use), which has to monitor some equipment at our house, and goes by the cunning name "eqmon".  It will be started at system startup, and should run all the time.  The source code is in one directory, under source control, and with a Makefile that does all the compilation/install (the main executable is in Python, so little compilation is required).  The daemon runs as root; while that would not be optimal on a system that's exposed to the public network or has malicious users, on a shielded home system that is convenient and low-enough risk; improving this to run as a dedicated user (with little escapes for things that really need root, such as attaching to hardware) is on my to-do list, but not terribly urgent.  Again, for something that ships to the public or is used on public machines, it would be the highest priority.

The question is: where to place some of its "things" in the file system?

The executable itself is obvious: /usr/local/sbin/eqmon.  There are some ancillary executables, used to show status and send it commands, which go into /usr/local/bin/eqstat and /usr/local/bin/eqcmd.  There are a few CGI scripts which allow interaction via web pages, which go into the same directory as the root of my local Apache server.  All this is easy.

To start it, I use the normal rc system, with a script in /usr/local/etc/rc.d/eqmon, which leaves the PID of the running daemon in /var/run/eqmon.pid.  The log files go into a subdirectory, namely /var/log/eqmon/, and there are several of those: daily human-readable log files showing what is happening to the daemon (startup, shutdown, errors, warnings, configuration changes), and some binary files that contain recent measurements.  The daemon itself creates new log files daily.  Since I insist that the log file name contain the date (their format is simply eqmon_YYYYMMDD.log), I still need to figure out how to interface that to `logrotate`, but that's a solvable problem.

But I have two questions left.  First, the daemon uses a local FIFO (not a TCP socket!) to communicate with programs that want to send it commands, and that FIFO has to be at a well-known place in the file system.  It does not need to survive OS crashes and reboots though, because the daemon will automatically recreate the FIFO when it starts.  So what is a sensible place for that?  /tmp/eqmon_cmd.fifo comes to mind, because it's OK if /tmp/ is cleared on reboot.  But I like to have /tmp neat and clean (meaning: mostly empty).  Is there a better place?  Is there some convention?

The second question is similar.  The daemon frequently dumps out its current state, both in a text format, and in a binary form (pickled Python objects).  This is for a variety of reasons: to help debugging (obviously, the code is still full of bugs), to enable it to restart after a crash without losing accumulated internal state (it still crashes regularly, it's a work in progress), and to simplify displaying the current state in a developer-friendly format.  These files ought to survive a reboot or OS crash, to /tmp is not appropriate (since that may be on a RAM disk, although at my house it isn't, with an SSD for the root file system, performance of /tmp is not relevant to me).  So where to put these two files?  

For now, I have all three things in in /var/run, with the names eqmon_cmd.fifo, eqmon_state.txt and eqmon_state.pickle.  There is lots of precedent for other subsystems dumping their stuff there (devd, ld, lpd, moused, named), although some of them use their own subdirectory.  So maybe I should "monkey see, monkey do", and follow those examples.  On the other hand, "when in Rome do like the Romans", and that should be done by studying the rules.

So are there rules, guidelines, or traditions?


----------



## wblock@ (Jul 31, 2014)

I'd say /var/ is the right place.  Maybe hier(7) will help.


----------



## fonz (Jul 31, 2014)

/var/run/ sounds like the right place for the FIFO. For the state files, I suppose you could consider making a directory /var/db/eqmon/ or even /var/eqmon/. Putting executables in /usr/local/(s)bin/ and rc scripts in /usr/local/etc/rc.d/ sounds fine to me.

On a personal side note though: I prefer to keep home cooking, err, I mean things that do not come from the ports collection, in a /opt/ hierarchy. When /opt/ is used, it appears to be customary to have a directory hierarchy for every "product" there, so you'd get /opt/eqmon/(s)bin/, /opt/eqmon/etc/(rc.d/), /opt/eqmon/data/ and so on. Only the FIFO might be better placed in /var/run/ than in /opt/eqmon/var/run/, but that one is perhaps somewhat subject to personal preference. Or as a compromise, symlink the latter to the former.

Edited to add:
To illustrate: applications I (have) use(d) that are not in ports include Nicotine+ (basically a Soulseeker client) and Maple (a really fancy-pants mathematics program). I install(ed) those in /opt/nicotine/ and /opt/maple/ respectively and let them sort out their own directory trees from there. Ironically, stuff that I make myself usually goes into /opt/bin/, /opt/lib/, /opt/include/, etc.

Also edited to also add _[sic]_:
The choices you've made seem perfectly sound to me, but to throw in another proverb: there's more than one way to skin a cat. Or as they say in my native tongue: there are several roads leading to Rome


----------



## phoenix (Jul 31, 2014)

The other option is to build it as a local port, and thusly add it to the normal /usr/local hierarchy.    Great for learning how the ports tree works, as well.


----------



## fonz (Jul 31, 2014)

phoenix said:
			
		

> Great for learning how the ports tree works, as well.


That much is true


----------

