systemd integration of procServ

[mdavidsaver]

systemd integration of procserv along the same lines as my sysv-rc-softioc. With the adoption of systemd by both debian and redhat, I think this work might reasonably be included with procServ itself. If this isn't desirable, I can maintain it as a separate package.

Provides some helpers for creating/maintaining procserv instances managed as systemd new-style daemons.

Locations:

• Configuration files defining instances.

/etc/procServ.conf /etc/procServ.d/*.conf

or

~/.config/procServ.conf ~/.config/procServ.d.*.conf

These contain blocks like:

[instancename]
command = /bin/bash
## optional
#chdir = /
#user = nobody
#group = nogroup
#port=0  # default to dynamic assignment

systemd generators generate unit files from this.

These can be managed by hand and/or with the 'manage-procs' CLI utility.

usage: manage-procs [-h] [--user] [--system] [-v]
                    {status,list,add,remove,write-procs-cf} ...

positional arguments:
  {status,list,add,remove,write-procs-cf}
    status              List procServ instance state
    list                List procServ instances
    add                 Create a new procServ instance
    remove              Remove a procServ instance
    write-procs-cf      Write conserver config

optional arguments:
  -h, --help            show this help message and exit
  --user                Consider user config
  --system              Consider system config
  -v, --verbose

Instances defined in /etc are managed by the global systemd instance. Those in ~/.config are managed by this user's systemd instance.

In addition a script 'prtelnet' takes an instance name, looks up the port and exec 'telnet'.

An example conserver config is provided to go along with "manage-iocs write-procs-cf".

Two options for handling log files are provided: rsyslog and "manual". The rsyslog option also includes logrotate.

This is intended to be a complete, integrated, solution. However, several pieces are usable in isolation. eg. handling of log files is independent of the config files and scripts described above except for the daemon name beginning with "procserv-".

I've include only rsyslog config as this is the default for debian 8. I'd like to get syslog-ng config as well.

An open question for me is the suitability of depending on python 3 for the scripts. At the moment they run with both 2.7 and 3.4. Requiring >=3.4 would allow the embedded "copy" of shlex.py to be dropped.

[ralphlange]

Is that good and complete enough to go into the official Debian distribution?

[ralphlange]

I mean in terms of python packaging guidelines, required documentation and manpages etc.

[mdavidsaver]

This is an open question for me. I think it could be without too much more work.

[mdavidsaver]

I'd first like to establish that this code fills a functional need. If so, I'll finish the necessary documentation.

[ralphlange]

I have been trying to sell your latest additions (that don't require port numbers for local access) as the way to avoid the extra configuration. How well does that go with these tools? Not really, does it?

[mdavidsaver]

How well does that go with these tools? Not really, does it?

It appears in the generated conserver config (conserver understands unix sockets), and the 'prtelnet' wrapper which looks up a tcp port using the /control file.

There are several pieces to this work:

1. automatic creation of unit files (avoids boilerplate)
2. management of log files. Decoupled other than the daemon name.
3. access to instance console (via conserver and/or 'prtelnet'). Decoupled other than the /control file.

These are based around a common set of conventions related to systemd:

1. daemon names are "procserv-*"
2. "/run/procserv-*/control" for daemon discovery and introspection

[mdavidsaver]

These are based around a common set of conventions related to systemd:

I was getting these confused

• daemon names are "procserv-*"
• "/run/procserv-*/control" for the unix socket
• "/run/procserv-*/info" for daemon discovery and introspection

[darcato]

Any update on this pull request? The feature would be quite useful.