[systemd-devel] PgSQL, MySQL systemd services - how to rewrite complex init scripts?
lennart at poettering.net
Sat Apr 9 12:50:39 PDT 2011
On Sat, 09.04.11 18:28, Michał Piotrowski (mkkp4x4 at gmail.com) wrote:
> 2011/4/9 Tom Lane <tgl at redhat.com>:
> > 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.
> It seams to me that implementation of ExecMycustomaction can solve
> this, but I'm afraid that Lennart will not want to implement such
That is correct, I don't think adding support for additional verbs is
the right thing to do.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel