Need some advices moving a fedora package from sysVinit to systemd t

Lennart Poettering mzerqung at 0pointer.de
Mon Jun 17 21:46:56 UTC 2013


On Mon, 17.06.13 16:05, Jean-Marc Pigeon (jmp at safe.ca) wrote:

> First question:
> Sysadmin can choose about data-base to use (postgresql or MySQL,
> editing the config file) and tuning configuration process will check
> proper data-base server
> is up and running then create application data-base according a
> configuration variable named "DB_TYPE". I can use "After=" directive
> with daemon server (lets say postgresql.service) but sysadmin could
> decide his production server to only use MySQL.
> So the service "After=" directive should be conditional to an env variable.
> I have seen no provision within systemd to resolve such case... Could
> somebody propose
> a nice way to resolve such needs within systemd service file? (if this
> is achievable?).

You can add After= for both databases. After= orders units only if they
exist, and if they don't htey have no effect. Hence simply lists all
database services you support and you should be fine.

> 
> Second question:
> ExecStartPre allow me to start a shell script file (which is used to
> check|do the initial config sequence),
> it is my understanding it is not wise (almost forbidden) to start
> daemon within this shell script, is
> calling systemctl (restart, start) allowed? (basically; is systemctl
> calling another systemctl technically sound?).

All processes started by ExecStartPre= will be killed before ExecStart=
is run. You cannot fork long-running processes from that.

It's usually a bad idea to run systemctl from ExecStartPre= since that
hides dependencies. With Wants= and After= you should have all you need
to make these depdendencies explicit.

If you have various bits you need to run in order to get your service
up, it's a good idea to simply split up the logic into two unit files,
and pull in one from the other and add ordering between them. This makes
it unnecessary to invoke systemctl from ExecStartPre= or any other such
command.

> Last question:
> When our deamon start, there is a small delay before it set a lock-pid
> (the lock pid is set only
> when daemon know its configuration is sound and going in daemon
> background mode). This lock pid is not
> yet available  within PIDFile when the process started by ExecStart exit.
> So systemd complain about the fact the daemon never started (which is
> not true, daemon is up and running).

Use Type=forking. That will cause systemd wait for the initial process
to exit before checking for the PID file.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list