Bruno Wolff III <bruno@xxxxxxxx> writes: > Tom Lane <tgl@xxxxxxxxxx> wrote: >> See also bug #832029 before being in too much of a hurry to decide that >> this Must Be A Good Thing. At minimum, it currently seems that we might >> need per-service tuning of the restart timing parameters before being >> sure that enabling restart is safe. So while recommending that services >> enable this after suitable testing *might* be a good idea, turning it on >> by default seems like a horribly bad one. > Since 832029 is not a public bug, can you give the gist of the issue? Ah, sorry about that. The deal is that mysqld has historically been automatically restarted after crashes by a supervisor script mysqld_safe. When we went over to systemd-land we said "hey, systemd can do that, and we'll have one less process required". However, it's not working so well: (1) systemd is not able to distinguish a crash that should be restarted from, say, failure due to misconfiguration in /etc/my.cnf. (It's not clear whether restart settings other than "always" would help here, but in general it seems obvious that there are likely to be service- specific reasons for restarting after some failures and not others.) (2) Right now it appears that there is a bug in systemd that causes it to ignore its respawn limits, such that if mysqld is indeed exiting immediately due to misconfiguration, it gets restarted immediately. Lather, rinse, repeat. Indefinitely. (3) Even if StartLimitInterval/StartLimitBurst were operating properly, there are scenarios where mysqld will fail to start up, but be slow enough about it (like a couple of seconds) that systemd's respawn suppression logic would not get triggered, so it'd keep on restarting it. So we'd probably need custom-tuned values of those settings if we decide to stay with using systemd for restart logic. I assume that (2) is just a bug that's going to get fixed pretty quick. But (1) and (3) seem like likely risk spots for other services. In the meantime I'm seriously considering reverting to mysqld_safe. regards, tom lane -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel