Lennart Poettering <lenn...@poettering.net> writes:
> On Wed, 27.06.12 14:50, Honza Horak (hho...@redhat.com) wrote:
>> One of the issue is (in)ability to imitate the original behavior of
>> mysqld_safe, which restarts the main process only if it crashes and
>> the pid file isn't properly cleaned up.
> I am pretty sure "on-abort" is actually what you really want here, no?
> The PID file checking sounds like a hack to achieve the same?
Well, it may be a hack rather than the nicest possible solution, but
here's the thing: every production installation of mysql in the world
runs underneath mysqld_safe, and has done for the last ten years or
more. The server's behavior has been designed, or at least evolved, to
fit that script's behavior and vice versa. If we try to use systemd's
restart functionality with a slightly different set of conditions for
restarting after crashes, we are likely to be finding ourselves
endlessly patching the server to make its corner-case behaviors fit
systemd. Patches which there is no chance upstream will take back,
because they'll say "why don't you use mysqld_safe like everybody else
does?"
So basically, what I foresee here is unproductive make-work, and so
I don't want to go down that path. Getting rid of one usually-idle
shell process isn't valuable enough to justify ongoing maintenance
headaches.
>> Another issue is the PID file guessing.
> Hmm, does mysql fork on its own?
mysqld proper does not. The reason we have to use type=forking is
that we're launching mysqld_safe and having it prepare the arguments for
mysqld (which is quite a few hundred lines of shell code we'd rather not
reimplement), then launch the daemon, and then exit (instead of waiting
for the daemon to terminate as it usually does). So from systemd's
perspective it's a forking server and PID guessing (or a PIDfile) is
necessary.
We could dodge that problem by having the script "exec" the daemon
instead of launching it as a subprocess. If memory serves, we tried
that initially and it didn't work because SELinux objected. We could
of course get that detail of the security policy changed, and probably
would if we were going to stick with this path.
> Normally a SysV daemon should have a clear initialization phase that it
> informs the init system about by double-forking (and returning in the
> parent). And the PID file should be written in that initialization
> phase, and the parent should return *only* after the PID file has been
> sucessfully written.
Unfortunately, you're just spinning theories out of whole cloth here
about what a daemon "should" do. I don't think reality agrees with
this. Certainly neither mysql nor postgresql have ever guaranteed any
such thing. Historically their init scripts have waited until the
server responds to client contacts before supposing the service is up,
anyway --- the existence of a pidfile just isn't that interesting from
the perspective of a client wanting to know whether the service is up,
or even whether it can be expected to come up shortly. (In both
databases, there can be a long and not-certain-to-succeed data recovery
operation occurring after the pidfile is established. It's typical to
not want to consider the service "up" till that's complete.)
> I think the best way to solve this really is to fix MySQL to either only
> exit in the parent when initialization is complete, or to invoke
> sd_notify() as described above.
Basically, we have no interest in maintaining such patches forever,
and no expectation that upstream would take them back either. If that
aspect were the only rough spot in using systemd we might be willing
to trouble over it, but there are enough other showstoppers in front
of it that we're just not going to reach that question.
regards, tom lane
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
