Distribution Init scripts (sys-v, systemd, etc.)

Terry Burton via Argus-info argus-info at lists.andrew.cmu.edu
Tue May 24 07:26:40 EDT 2016


Hi Carter,

I hope you are well.

It's been about a year since I last looked at Debian packaging and
having recently upgraded our platform to Jessie which defaults to
systemd I have been giving the init script a little thought.

Currently argus supplies support init scripts that set up a basic
argus -> radium -> rasplit pipeline for logging the "em2" interface to
the local filesystem. The distribution-specific init scripts follow
this lead resulting in an installation that is mostly broken upon
install for the majority of users this is unlikely to match their
expectations.

Getting things up and running requires the user to duplicate and
customise the provided init scripts (or .service files) per
argus/raclient instance - taking care to avoid lock file clashes and
such in the sys-v case. As this process is very specific to their
environment it is non-trivial to document centrally - and distribution
maintainer are usually too lasy to write specific documentation ;-)

What if instead we were to provide a framework that makes it easier to
configure individual instances of the argus/raclient daemons that aims
to somewhat platform/initsystem-agnostic?

For example, the installation/packaging could create
/etc/argus/instances beneath which the user creates a subdirectory
with an arbitrary instance name for each argus/radium/rasplit
instance, etc.

$ tree /etc/argus/instances/
/etc/argus/instances/
├── eth1-192.168.0.1
│   └── env
├── eth3-123.123.1.1
│   └── env
├── radium
│   └── env
├── rasplit
    └── env

(Initially this could be pre-populated with the current simple "em2" example.)

Each instance contains a file, env, that contains environment
variables. Currently there is only one such variable, CMD, which
determines the command that is run.

Here's a basic example to illustrate the point:

$ cat /etc/argus/instances/eth1-192.168.0.1/env
CMD=argus -u argus -i eth1/192.168.0.1 -B 127.0.0.1 -P 564

$ cat /etc/argus/instances/eth3-123.123.1.1/env
CMD=argus -u argus -i eth3/123.123.1.1 -B 127.0.0.1 -P 565

$ cat /etc/argus/instances/radium/env
CMD=radium -u argus -S 127.0.0.1:564 -S 127.0.0.1:565 -B 127.0.0.1 -P 569

$ cat /etc/argus/instances/rasplit/env
CMD=rasplit -u argus -S 127.0.0.1:569 -M time 5m -w
/var/log/argus/%Y-%m-%d/$srcid-%H:%M:%S.arg

systemd has an "instances" feature that make using this trivial. It
expands references to "%i" with the part after an @ symbol in the
.service filename. So you can have a single template service file as
follows:

$ cat /lib/systemd/system/argus at .service
[Unit]
Description=UoL Argus instance %i
After=network.target

[Service]
Type=simple
EnvironmentFile=/etc/argus/instances/%i/env
ExecStart=/usr/bin/env $CMD

[Install]
WantedBy=multi-user.target

Which can be enabled per argus/raclient instance as follows:

systemctl enable argus at eth1-192.168.0.1
systemctl enable argus at eth3-123.123.1.1
systemctl enable argus at radium
systemctl enable argus at rasplit

This scheme should be harmonious for both systemd and sys-v since you
could have a common sys-v init script (say /etc/init.d/argus) that is
enabled via per-instance symlinks in the rcN.d directories, e.g.
/etc/rc2.d/argus at eth1-192.168.0.1. The init script inspects it's $0 to
obtain its instance-specific name, sources /etc/argus/instances/$0
(-ish), and invokes the daemon contained in $CMD.

The benefit is that for most setups the user is never doing anything
other than configuring the /etc/argus/instances subdirectories then
enabling the services according to the specifics of their init system.

Do you think that this would be a useful abstraction and can it be
easily extended to other init systems that you are familiar with in
the argus ecosystem? If so then I'm happy to update the systemd and
sys-v init configuration in the Debian packaging which you can then
modify for Centos, BSDs, etc.


All the best,

Terry



More information about the argus mailing list