[systemd-devel] mysqld about back to use mysqld_safe in Fedora
Kay Sievers
kay at vrfy.org
Wed Jun 27 10:16:42 PDT 2012
On Wed, Jun 27, 2012 at 1:06 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Wed, 27.06.12 16:49, Honza Horak (hhorak at redhat.com) wrote:
>>
>> On 06/27/2012 02:50 PM, Honza Horak wrote:
>> >Another issue is the PID file guessing. It usually works fine, but if we
>> >want to be sure what pid is monitored, we should use PIDFile= option.
>> >However, when we use this we don't know when the pidfile is created,
>> >while waiting some sane time is not a nice solution and could bring
>> >another issues. Using notify feature doesn't helps us, since we used
>> >Type=forking.
>>
>> Thinking a bit about this issue, it would be good if systemd had
>> something like WaitForPidFile=true option and didn't leave
>> ExecStart= section in this case until the pid file (specified by
>> PIDFile=) would be created. Using this we could possibly get rid of
>> scripts like mysqld-wait-ready, which simply wait for service to be
>> ready. Thoughts?
>
> Hmm, it might actually make sense to introduce a Type=pid-file or so
> where the service can fork as much as it wants and we consider it up
> only after the PID file has been created and closed. We could watch that
> with inotify.
>
> Michal, Kay, opinions?
>
> Of course, I am not a fan of adding too many compat kludges, but this
> one sounds pretty OK to me, and would probably solve things for a lot of
> services which write the PID file too late. It's the kind of thing which
> keeps our bugzilla noise small without being too ugly to support.
Sounds ok.
We have a bit of inotify watch on pid files already, for broken things
like sendmail, which seem to only work reliably with slow shell
scripts starting it, and where the maintainers don't see and
understand the brokenness and refuse to fix it.
We have to deal with that stuff in a way I guess. I wouldn't mind
though, if the option had "broken" or something like that in the name.
:)
Kay
More information about the systemd-devel
mailing list