On Sat, 09.04.11 18:28, Michał Piotrowski (mkkp...@gmail.com) wrote: > > 2011/4/9 Tom Lane <t...@redhat.com>: > > Gustavo Sverzut Barbieri <barbi...@profusion.mobi> writes: > >> 2011/4/9 Michał Piotrowski <mkkp...@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 > feature.
That is correct, I don't think adding support for additional verbs is the right thing to do. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
