Add systemd service to Debian package

[MichaIng]

Did you thing about a systemd service? Something like:

[Unit]
Description=vmtouch
Documentation=https://github.com/hoytech/vmtouch/blob/master/vmtouch.pod
DefaultDependencies=no
After=local-fs.target
Conflicts=shutdown.target
Before=shutdown.target

[Service]
EnvironmentFile=/etc/default/vmtouch
ExecStart=/usr/bin/vmtouch $VMTOUCH_OPTIONS $VMTOUCH_FILES

[Install]
WantedBy=local-fs.target

A problem is that it does not work with the same options as the sysvinit service does (default environment file):

• -d would require Type=forking and at best a PID file then as well. But for systemd it is not required and IMO preferable to get binary output as well, to run it with default Type=simple and no daemon mode.
• User/Group cannot be applied with VMTOUCH_USER_GROUP variable (?), or it would require to separate it in an ugly ExecStartPre step or something.
  • However according to Potential future breakage on linux #74 it might be anyway required to run it as root and a systemd service could be instead hardened another way: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Sandboxing
• ENABLE_VMTOUCH IMO does not make any sense at all. Instead of changing this variable, one should simply disable the service.

[hoytech]

Hey, actually I'm more inclined to remove the service/daemon stuff from the debian package. Running it as a daemon is actually a fairly uncommon use-case. Usually people use vmtouch as an interactive tool, or in a cron job. The daemon only makes sense when you're doing memory locking, and there are a lot of different ways you might want to do this, it's hard to make a fully generic service definition, I think.

[MichaIng]

@hoytech
Basically, if the service implementation allows to freely adjust the command arguments, it can be reasonable in all cases, e.g. lifting certain files into cache once at boot only, or obtaining current fs cache situation and store or print it somewhere etc. But yeah in many cases that would need a service adjustment as well, e.g. change Before=/After=, default output or a timer and such. At least the service allows to run it with a fixed user and environment repeatedly.

Our little distro/overlay uses now vmtouch as a replacement for a tmpfs to store scripts and settings files for fast execution/reading. The tmpfs has the large disadvantage that files need to be copied there on boot and stored back to disk on shutdown. Editing them on disk is overwritten and a system crash causes changes to be lost. So using the native fs cache is much better, as long as one does not care about fs writes, e.g. when worrying about SDcard wear, in case of plain text config files not an issue... Generally I think that it could be omitted completely, since native fs cache is already done nicely on regularly read files, but I didn't want to loose the performance boost completely for now. But indeed we use an own compiled deb package with an own service file and default config, hence having this in upstream is not necessarily required.