Proposal: Potentially Useful openrc Feature

[John R. Graham]

I'm managing a project using another distribution, CentOS, at my place of business. Sacrilege, I know, but it's not my choice right now—and I do make sure to wash my hands after working with it. Also, I did all the prototype work on Gentoo before moving on to the mandated production environment.

Here's the background information. We're bringing up a high availability database cluster based on MariaDB and Galera Cluster. During cluster bring-up, one node has to be chosen as the "source of truth" which other nodes use to get their initial database snapshots. This is accomplished on Gentoo (running openrc as the init system) by placing an additional command line option in /etc/conf.d/mysql in MY_ARGS called "--wsrep-new-cluster". Database nodes that aren't the initial source of truth get a blank MY_ARGS. After the cluster is up, any node can be a source of truth for further node joins so the argument is removed from the initial source of truth /etc/conf.d/mysql and the mysql service is subsequently restarted.

But on CentOS, it's just a little bit easier. (Out of the box, CentOS uses systemd as its init system.) The service command takes extra arguments after the [start|stop|restart|etc] argument that get passed to the daemon on startup, like this

[ct85711]

Just my 2 cents, I can see where this can be useful to have for allowing temporary configuration settings. The only thing I see as a potential issue, is what gets precedence, the configuration file or the passed settings. I would more of go by the configuration file gets read first, and the passed arguments is then passed. (though this can cause issues between different services if they use the first configuration or the last one).

[szatox]

I've seen it done in percona by replacing "start" with "bootstrap" in "service mysql start" line.
It was also possible to provide extra argument on the command line directly, which resulted in equivalent command being called by the init script.
It's actually very important to make such start a manually triggered event. Definitely not something you want to put in your config and then forget about it.
You don't need any bootstrap nodes in a running galera cluster at all. Regular start will make that node join cluster and update its own data based on peers, or shut down immediately, which is reasonably safe. A node hard-coded with this option will always start in bootstrap mode leading to split-brain scenario which can damage your data. Don't do that.

[John R. Graham]

Hi, szatox.

I think you're missing the point of my post, or else I'm missing yours.

[khayyam]

John ... the following might offer a solution for your particular use case:

[krinn]

https://bugs.gentoo.org/show_bug.cgi?id=427144

if you think about your issue, it's as easy as doing:
add a new section in the initscript
extra_commands="clusterinit"
clusterinit() {
// copy start-stop-deamon line from start() and add the extra opts there
}
/etc/init.d/maria clusterinit instead of start

or add in start() a test -e /tmp/cluster-init and if none, start-stop-deamon ... , if present start-stop-deamon ... --wsrep-new-cluster

there's also, extra_started_command and extra_stopped_command but i cannot put hands on doc for them, i just know them because of a bug i met in openrc times ago.

and times ago i remember myself changing nfs init script (in order to check if server was up before running all nfs mount that will stall for hours because it trys every mount even first mount has already fail as server is down), and after one or two nfs update, i simply rename it to some "ifserverup" to stopped getting bug by etc-update change on nfs service

but whatever you wish do with openrc: i agree!!! if it stuck you into maintaining it, i'll be more than happy

[John R. Graham]

Thanks, krinn. I should've looked. However, that bug seems to have run aground on a discussion of a much more complex implementation involving, among other things, something called "virtual init scripts" where, for example, you would no longer need to create a symlink between net.lo and net.your-nic-name but would run the initiscript as

[krinn]

[steveL]

[John R. Graham]

[John R. Graham]

[steveL]

[John R. Graham]

I've never used it either, but I think breaking backwards compatibility would be a quick way to get a humbly-submitted feature request with accompanying implementation rejected out of hand, which leads me to the opinion that we shouldn't reject backwards compatibility out of hand, either. That said, there's a lot to be said for the simplicity of the argument parsing with a single command. Furthermore, the overwhelmingly most common double command pair in my opinion, "stop start", is automatically synthesized into "restart" by rc-service: almost none of the init scripts actually contain a restart target.

Perhaps we could brainstorm about syntax to see whether the result can be made not to be atrocious. It appears that individual init scripts would not see this complexity at all because it would be implemented in rc-service.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[Hu]

[Ant P.]

This seems like a bad idea in the long run, but beware my view might be biased slightly from prolonged runit use

In OpenRC's case there's already a way to do this: env vars. /etc/{init,conf}.d files are just posix shell scripts, after all. The example in the first post can already be done (in a slightly ugly way) *without* code changes:

[John R. Graham]

[Ant P.]

That doesn't work in OpenRC? Sorry, I'm not as clever as I thought then. Maybe conf.d overrides the command line, it ought to work the other way around. Doesn't help that the order of evaluation isn't documented anywhere...

And what I'm getting at is that — while it looks convenient at first, and safe for things like what you want to do — it has the potential to be a huge footgun for newbies: imagine someone finds this handy shortcut for something they think they need to do a lot, they decide they'll just cut a corner instead of writing down anything permanent, they come back the next day and realise they can hit ^R to pull it out of .bash_history, then they get into the habit...
...and then 3 months down the line bash decides to save a 0 byte history file (again). Or something happens along those lines. Maybe their muscle memory isn't as great as they thought. Either way, they're gonna have a bad day.

I've done it to myself often enough over the years to recognise the signs. Sometimes hard things should be hard.

[John R. Graham]

Since I didn't know either way, I took the trouble to verify what was going on. What's actually happening is that init scripts are run from a fresh /etc/profile environment; so you can push something into the init script environment by making an entry in /etc/env.d/, but not from the running shell environment.

Thanks for explaining more thoroughly. It's probably worth mentioning that it's possible to forget about temporary changes made to the permanent configuration files, too, which is a mistake I have made before. Now, I'm not saying that balances the scales: I do think the feature I'm proposing creates more opportunity for noob foot shots. Philosophically, though, I fall closer to the, "Don't dull my tools," school; and I'm not sure I agree that the addition to the noob minefield is "huge". It's worth thinking about, though.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[szatox]

Interesting...
Well, I'm all in for a patch that would allow us provide special options to init scripts, be it an agrument, a variable, or a special command.
Talking about a pitfall for noobs, init scripts tend to come with software and just work, so they are of little interest to people not ready to deal with them. I mean, these kernel panics and can't find root device errors during boot are a bigger concern, right?

[steveL]

[John R. Graham]

As an alternative for consideration, let me say that I kind of like krinn's suggestion. In practice, I think it would look something like this:

1. Backwards compatible (no arguments):

   Code:

   rc-service mysql stop start

   identical to what we have today.
   
2. Stop with no arguments but start with argument(s):

   Code:

   rc-service mysql stop start: --foo bar

   
   
3. I believe the synthesized restart command should be equivalent to the above if invoked like this:

   Code:

   rc-service mysql restart: --foo bar

   
   
4. In the odd case where stop needs arguments but start doesn't:

   Code:

   rc-service mysql stop: --foo bar start:

   In other words, if any command needs an argument, all (following) commands would need to carry the ':' suffix. That's the only small wart I see so far.
   
5. Finally, in the even more odd case where an argument needs a colon, escape merely that:

   Code:

   rc-service mysql stop start: --foo\\:bar

   which is the standard *nix answer to include special characters in non-special contexts.

Options to the rc-service command itself still live comfortably before the service name. One advantage of this approach is that the colon character is one that doesn't normally need to be escaped. Another advantage is that (in my opinion) it reads rather intuitively.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[steveL]

I prefer the -- separator, whose appearance is immediately obvious as it must appear before any cmd, to trigger parameter passing.

I don't think robustness of allowing for weird paths starting with a '-' is required, for temporary usage from the console (rather than scripting.) Any paths like that are not going to be robust in daemon usage either, so can only be an error.

No escapes required, just the usual option processing and consumption.

[krinn]

[John R. Graham]

[John R. Graham]