[systemd-devel] SysVInit service migration to systemd

[Mantas Mikulėnas]

On Fri, Jun 26, 2015 at 4:15 PM, Lesley Kimmel <ljkimmel99 at hotmail.com>
wrote:

> Hi all;
>
> I've been working with RHEL5/6 for the past several years and have
> developed many init scripts/services which generally use lock files and PID
> files to allow for tracking of the service status. We are moving to RHEL7
> (systemd) in the near future and I am looking for instruction or tutorials
> on how to effectively migrate these scripts to work with systemd.
>
> I found https://wiki.archlinux.org/index.php/Systemd#Service_types which
> seems somewhat promising but it is fairly high-level. It looks like I may
> be able to use the 'forking' type with the 'pidfile' parameter to somewhat
> mimic what the scripts to today. However, I have a couple of questions:
>

Usually systemd detects the main process even without PIDFile, using
cgroups to keep track.


> -How does systemd track whether it should be stopping a service at
> shutdown (analogous to the /var/lock/subsys files in SysVInit)?
>

All service control requests go through the always-running init process, so
it can just keep track of service status internally without having to write
it out.

[This also means services run in a clean environment and can't ask for
interactive input when starting. Upstart and even /etc/inittab also work
the same way.]

Systemd also monitors whether the service processes are actually running –
by putting each into a separate cgroup – so it generally avoids issues such
as stale pidfiles.


> -Are there merits to using the notify or dbus types? If so does anyone
> know of a tutorial I could use to get to that point? (FYI, I'm not a
> developer but I learn complicated things quickly).
>

Similar to Type=forking, they both let systemd know whether the service is
ready or still initializing (which can't be done with the default
Type=simple).

Type=dbus might be best for creating DBus-activatable services compatible
with regular dbus-daemon, since it has mostly the same expectations as
dbus-daemon: the service doesn't fork, and is considered ready as soon as
it finally claims the configured BusName.

Type=notify is somewhat more lightweight – the service just needs to send
READY=1 over a Unix socket. (The service can also show some additional
information in `systemctl status` – e.g. lldpd could send "STATUS=No
neighbors"). libsystemd has sd_notify(3)
<http://www.freedesktop.org/software/systemd/man/sd_notify.html> for this,
though it could be done using regular socket API.

I suppose the same notify socket could be exposed to all other service
types. I don't know why it isn't yet.


> -If the current service logs to a custom, dedicated log is there a way to
> get systemd to provide the same type of output that it does for the
> built-in system services or must I make some modifications to integrate
> with journald?
>

`systemctl status` only reads from the journal.

The journal, however, also receives messages sent using the traditional
syslog API or written to the kernel log – in addition to its native
sd_journal_send(3)
<http://www.freedesktop.org/software/systemd/man/sd_journal_send.html> – so
that already covers most services.

You could also use rsyslogd to feed messages from custom text logs into the
journal, using its omjournal module.

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150626/6cd8734c/attachment.html>