Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them
* Michael Orlitzky schrieb am 02.12.21 um 08:05 Uhr: > On 2021-12-02 08:12:55, Alec Warner wrote: > > > > Can we automate any of it? Emit QA warnings? etc. > > > > I would love to be proven wrong, but I don't think so. We have two > main problems. First, The service scripts are POSIX sh, which is > better than bash, but still can't easily be parsed for semantic > information. > > Second, if the daemon is "special," then the service script is > justified in being similarly unconventional. Unusual runtime behavior > can't be statically detected, and I doubt that the well-behaved > portion of daemons in the tree is large enough that we can warn about > every script that smells a little bit fishy. For "special" daemons, the ebuild could just set a QA_* variable to silence a qa warning if required. -Marc
Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them
On 2021-12-02 08:12:55, Alec Warner wrote: > > Can we automate any of it? Emit QA warnings? etc. > I would love to be proven wrong, but I don't think so. We have two main problems. First, The service scripts are POSIX sh, which is better than bash, but still can't easily be parsed for semantic information. Second, if the daemon is "special," then the service script is justified in being similarly unconventional. Unusual runtime behavior can't be statically detected, and I doubt that the well-behaved portion of daemons in the tree is large enough that we can warn about every script that smells a little bit fishy.
Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them
On 12/2/2021 7:34 AM, Michael Orlitzky wrote: On 2021-12-01 21:02:20, Brian Evans wrote: After a cursory scan of the Gentoo repository, I've noticed an overabundance of start_stop_daemon_args being declared in scripts committed. I would like to draw attention and see if we can clean these up together. A lot of this is covered in the service script guide: https://github.com/OpenRC/openrc/blob/master/service-script-guide.md There's a 2.5-year old bug to mention it in the devmanual: https://bugs.gentoo.org/684354 For sure, there are several points that document covers that are reiterated here. However some variable options are not covered there. They do exist in the openrc-run manual. My main point is how to best use these options and that some scripts are not taking full advantage. Brian OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them
On Thu, Dec 2, 2021 at 4:34 AM Michael Orlitzky wrote: > > On 2021-12-01 21:02:20, Brian Evans wrote: > > After a cursory scan of the Gentoo repository, I've noticed an > > overabundance of start_stop_daemon_args being declared in scripts committed. > > > > I would like to draw attention and see if we can clean these up together. > > A lot of this is covered in the service script guide: > > https://github.com/OpenRC/openrc/blob/master/service-script-guide.md > > There's a 2.5-year old bug to mention it in the devmanual: > > https://bugs.gentoo.org/684354 > Can we automate any of it? Emit QA warnings? etc. -A
Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them
On 2021-12-01 21:02:20, Brian Evans wrote: > After a cursory scan of the Gentoo repository, I've noticed an > overabundance of start_stop_daemon_args being declared in scripts committed. > > I would like to draw attention and see if we can clean these up together. A lot of this is covered in the service script guide: https://github.com/OpenRC/openrc/blob/master/service-script-guide.md There's a 2.5-year old bug to mention it in the devmanual: https://bugs.gentoo.org/684354
[gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them
After a cursory scan of the Gentoo repository, I've noticed an overabundance of start_stop_daemon_args being declared in scripts committed. I would like to draw attention and see if we can clean these up together. The reason why these are important is the modular nature of the declarative syntax. For example, supervise-daemon should be available to any user for a declarative script by simply adding supervisor="supervise-daemon" to the corresponding conf.d file. There are many necessary options like --wait or --env which don't have a declarative replacement. These comments are for scripts without a start/stop function defined thereby relying on the default scripts in /lib/rc/sh/. There are other advanced cases for sure. I just want to discuss easy to forget options. Common mistakes included with start_stop_daemon_args: "--background --make-pidfile" ("-b -m") should be replaced by command_background="yes" (these are implied together) "--user" and/or "--group" should be command_user="user:group" (use root for user when only group is needed, the :group can be omitted) "--chdir /path/to/foo" (-d) should be directory="/path/to/foo" "--chroot /var/chroot/foo" (-r) should be chroot="/var/chroot/foo" "--stdout /var/log/foo" (-1) should be output_log="/var/log/foo" "--stderr /var/log/foo.err" (-2) should be error_log="/var/log/foo.err" "--pidifle /run/foo.pid" (-p) should be pidfile="/run/foo.pid" "--name foo" (-n) should be procname="foo" "--exec" (-x) should be deleted as it is included by default when command="" is declared (required to exist) In addition, command_args may need to be reevaluated for each script to split certain pieces out into command_args_foreground and command_args_background. command_args_foreground should include any options to force the daemon/script into the foreground instead of forking. command_args_background should include any option to fork a daemon and, optionally, to have it write a pidfile to monitor. (Cannot be used together with command_background option). command_args should not include the conditions of the other two in most cases. If anyone would want me to do work in obvious cleanups, I am open to bugs, patches or just committing. Comments welcome. Brian OpenPGP_signature Description: OpenPGP digital signature