[systemd-devel] PgSQL, MySQL systemd services - how to rewrite complex init scripts?

Lennart Poettering lennart at poettering.net
Sat Apr 9 12:54:44 PDT 2011


On Sat, 09.04.11 12:37, Tom Lane (tgl at redhat.com) wrote:

> Gustavo Sverzut Barbieri <barbieri at profusion.mobi> writes:
> > 2011/4/9 Micha?? Piotrowski <mkkp4x4 at gmail.com>:
> >> Postgresql script has perform_initdb(), initdb() and upgrade()
> >> functions. ...
> >> Mysql script also has some data dir creation code - I think it can
> >> also be moved to separated script.
> 
> > As mentioned with handful similar cases: this should be handled as
> > part of the daemon itself, not initscript.  That's the final solution
> > we should aim as it's the only sane place to do it.
> 
> [ shrug... ]  Users of these databases are accustomed to having that
> functionality provided in that way.  Not only does this mean fewer
> scripts to package, it guarantees that the initialization actions have
> the same ideas as the daemon start/stop actions about configuration
> details (eg, where the database files are located).  The daemon can
> *not* source that knowledge internally, at least not without destroying
> its configurability, so what you say above is a non-solution.
> 
> If you take an absolutist position that systemd scripts cannot be used
> for such purposes, that will either result in kluged-up solutions or
> non-adoption of systemd.  You'd be better off in the long run to realize
> that there is a reason for the traditional initscript infrastructure to
> provide extra "custom" actions for particular services, and to offer an
> equivalent capability.

Well, I think there's nothing absolutist on our position here... It's
not that we disallow the use of shell scripts. We are just saying that
systemd unit files aren't shell scripts and we don't want them to become
shell scripts.

You can always provide your own shell scripts alongside your package, or
even spawn shell scripts from systemd unit files.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list