Yes, and just like Runit's run and finish files to start and stop services cleanly, often unless the project wants to cater to a specific init system, which most do, or try to, the system distribution maintainer often gets stuck with the task of writing their own scripts for service management from the manpages and documentation, which sometimes is not cut and dry, and pretty much trial and error.

At least with the standard model of daemontools, runit, s6, bsdinit, and sysvinit, these are generally bash based shell scripts and require only instance based commands to start, stop, restart, or status check the services, and if the model uses it, checks for the execution state of a required dependency, and if found in the up or running status, launches the service, or if not exits and retries.

However, not always do these init service scripts provided by the project fit the needs of every distribution and design. Some just don't work out of the box regardless of what is done.

obviously you did not understand the content of TobiSGD post.

systemd running MySQL vs MySQL properly configured running with systemd

you should get simple things like this right.

1 members found this post helpful.

I did understand the context of the post, but frankly chose to attack it from the angle I did - problem? Yeah, I have a problem with RedHat and have a huge ax to grind against them- I'm free to put out that I'm not into they way they do things.

2 members found this post helpful.

The package maintainer for MySQL on Red Hat may or may not be involved with systemd (which by the way is a project with contributions from far more people than only Red Hat developers), I don't know. That there are some people at Red Hat that are developing for systemd does not mean that everyone at Red Hat is involved with systemd and it does not mean that no one at Red Hat can make a mistake or does spot problems with unit files that are provided by the service developers. If you feel that this is a bug then report it.
I merely wanted to point out that this is not a systemd problem, regardless how many axes you have to grind with Red Hat.

The developers of systemd don't really care about any bugs that are reported.

4 members found this post helpful.

and why should systemd devs care about a bug in the MySql package

or did you miss the context and felt just that its time for some senseless bashing?

1 members found this post helpful.

At first, while there are some bugreports which get the WONTFIX status by the systemd developers it is (almost) always reasonably explained why that is the case. This does not mean that all bugreports are dismissed by them.
Second, if you see there is a problem with the MySQL package why would you report that to systemd developers, who are (as I have already explained above) possibly not even involved with MySQL package maintenance at all? Naturally you would file a bug against the MySQL package, not the systemd package.

This causes me to ask you the question, if a similar problem with MySQL comes up with OpenRC, runit or s6, do you blame those developers or is that just the case for systemd?

Nope, no senseless bashing going on here. I was not at all referring to a bug in mysql, I was referring to bugs in systemd.

No, you were not. The unit file for MySQL is part of the MySQL package, not the systemd package. If the unit file does allow respawning of MySQL and with that possibly corrupts a database then the bug is in MySQL, not systemd.
The question remains unanswered if you would blame developers of other service supervisors for the same behavior or if this is only the case when systemd is involved.

This thread always makes me smile

Peter Jackson wants to make a trilogy based on it, as a follow-up to the Hobbit. Another spectacular epic.

1 members found this post helpful.

It took me until that post until I realized what your name meant Bravo!

Reminds me of Roosterteeth's name... (they couldn't just name their company Cock Bite)

1 members found this post helpful.

Hi,
For the post you are querying about it is general posting to the thread. If I want to direct to another member directly then I would quote that post. When you enter a thread the posts should be posted via time & date stamp to keep things in order. LQ threads keep the posts in line via post time stamp.

Hope this helps.

I never said it was a bug in systemd, rather its a lack of sane defaults for things that depend on systemd.

Anyways, there are plenty of other issues discussed. As you can discern from my user agent, I use FreeBSD, more than I use Slackware or Void, and the reason is that I find the FreeBSD project is doing things in a way that has a future, for now. If Jordan Hubbard gets his way, though, we'll have launchd eventually, and if that happens, I'll tell him to shove it up his ass and fork FreeBSD with a large proportion of support from FreeBSD users - most of them aren't happy with the way the Apple section of the OS is pushing their agenda anyways - we have plenty of time though as it likely won't happen till after the 11.0 branch is released as a release version.

1 members found this post helpful.

If a database daemon corrupts a database due to respawning I would consider that a bug, but anyways, that is the point I wanted to make: in the case you describe the defaults for this behavior are not set by the systemd team, the are set by the MySQL team, so there is no point in blaming systemd for it.
This is your right to do and though I am in favor of the systemd approach I would appreciate it, just because you actually would act like it , IMHO, should be in the open source world: you don't like something, you get the work done to change it.