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

[Gustavo Sverzut Barbieri]

On Sat, Apr 9, 2011 at 4:54 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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.

Exactly, we don't want to block people from doing it wrong, you can
still do it wrong with ExecStart or ExecStartPre, but our
*recommendation* is to do it right. And there is nothing that knows
the daemon behavior better than the daemon itself. It will know the
configurations, settings, compile-time defines, assumptions and
everything. Getting those offloaded to an external script will bring
you no good, just harm.
     As an example, if you do chdir("/var/lib/mysql") or
stat("/var/lib/mysql", &st) and you check for failure (as expected),
why not just create the directory and try again? What's wrong with
that? You can even be optimized to use dirfd() and *at() (openat())
variants to operate on those.


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202