[gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them

[gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them

[Brian Evans]

[-- Attachment #1.1: Type: text/plain, Size: 2307 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them

[Michael Orlitzky]

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

Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them

[Alec Warner]

On Thu, Dec 2, 2021 at 4:34 AM Michael Orlitzky <mjo@gentoo.org> 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

[Brian Evans]

[-- Attachment #1.1: Type: text/plain, Size: 872 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them

[Michael Orlitzky]

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

[Marc Schiffbauer]

* 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