[gentoo-user] Protecting init.d files from auto-update

[gentoo-user] Protecting init.d files from auto-update

[Peter Humphrey]

Greetings,

How can I prevent portage from auto-updating /etc/init.d/boinc?

I run BOINC on my machines, and /etc/init.d/boinc includes far too long a 
timeout on start-stop-daemon when stopping the program. The minimum time it 
will wait is 60s, which is a long time when you're waiting. On this machine I 
set 4, 2 and 1 seconds because I run only one BOINC project, to keep the heat 
down. My big machine runs 18 projects or more, and even there 60 seconds is 
way over the top (I can see the project's activity in gkrellm).

Anyway, what matter if a project is terminated abruptly and has to be 
restarted? It wouldn't be the end of the world.

I've tried adding the file to CONFIG_PROTECT in make.conf, to no avail. Any 
other ideas before I submit a bug report against sci-misc/boinc?

-- 
Regards,
Peter.

Re: [gentoo-user] Protecting init.d files from auto-update

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

On Tuesday 14 January 2025 11:28:21 Greenwich Mean Time Peter Humphrey wrote:
> Greetings,
> 
> How can I prevent portage from auto-updating /etc/init.d/boinc?
> 
> I run BOINC on my machines, and /etc/init.d/boinc includes far too long a
> timeout on start-stop-daemon when stopping the program. The minimum time it
> will wait is 60s, which is a long time when you're waiting. On this machine
> I set 4, 2 and 1 seconds because I run only one BOINC project, to keep the
> heat down. My big machine runs 18 projects or more, and even there 60
> seconds is way over the top (I can see the project's activity in gkrellm).
> 
> Anyway, what matter if a project is terminated abruptly and has to be
> restarted? It wouldn't be the end of the world.

I am not familiar with the BOINC application.  Is the program taking a long 
time to stop because it is completing whatever calculation it was processing 
and then have to store/upload the result and its current status before it 
shuts down?  If not, then I agree 60 seconds is a long time to wait.


> I've tried adding the file to CONFIG_PROTECT in make.conf, to no avail. Any
> other ideas before I submit a bug report against sci-misc/boinc?

The existing CONFIG_PROTECT in /usr/share/portage/config/make.globals ought to 
protect unwanted changes.  Have you inadvertently set CONFIG_PROTECT_MASK 
somewhere?

You can check what portage is configured to do with:

portageq envvar CONFIG_PROTECT

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Protecting init.d files from auto-update

[Arve Barsnes]

On Tue, 14 Jan 2025 at 12:28, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> Greetings,
>
> How can I prevent portage from auto-updating /etc/init.d/boinc?

I'm not sure what order things are sourced, but you could try putting
your edited stop() function in /etc/conf.d/boinc

Regards,
Arve

Re: [gentoo-user] Protecting init.d files from auto-update

[Michael Orlitzky]

On Tue, 2025-01-14 at 11:28 +0000, Peter Humphrey wrote:
> Greetings,
> 
> How can I prevent portage from auto-updating /etc/init.d/boinc?
> 

In this case the init script is using a custom variable for the
timeout, and setting that variable unconditionally:

  stop() {
    local stop_timeout="SIGTERM/60/SIGTERM/30/SIGKILL/30"
    ...
  }

What would be much nicer is if it


 1. Used the standard $retry variable for this (man openrc-run)
 2. Set $retry only if it's unset

Then you could simply provide your own $retry in boinc.conf. Going a
bit further, it could move the env_check into stop_pre(), and use
$pidfile instead of the custom $BOINC_PIDFILE. That would make the
entire stop() function redundant.

Re: [gentoo-user] Protecting init.d files from auto-update

[Peter Humphrey]

On Tuesday 14 January 2025 14:18:51 Greenwich Mean Time Michael Orlitzky 
wrote:
> On Tue, 2025-01-14 at 11:28 +0000, Peter Humphrey wrote:
> > Greetings,
> > 
> > How can I prevent portage from auto-updating /etc/init.d/boinc?
> 
> In this case the init script is using a custom variable for the
> timeout, and setting that variable unconditionally:
> 
>   stop() {
>     local stop_timeout="SIGTERM/60/SIGTERM/30/SIGKILL/30"
>     ...
>   }
> 
> What would be much nicer is if it
> 
> 
>  1. Used the standard $retry variable for this (man openrc-run)
>  2. Set $retry only if it's unset
> 
> Then you could simply provide your own $retry in boinc.conf. Going a
> bit further, it could move the env_check into stop_pre(), and use
> $pidfile instead of the custom $BOINC_PIDFILE. That would make the
> entire stop() function redundant.

That's v helpful, Michael. Thanks.

Do you mind if I quote you in the bug report I send in?

-- 
Regards,
Peter.

Re: [gentoo-user] Protecting init.d files from auto-update

[Peter Humphrey]

On Tuesday 14 January 2025 12:01:02 Greenwich Mean Time Michael wrote:

> I am not familiar with the BOINC application.  Is the program taking a long
> time to stop because it is completing whatever calculation it was processing
> and then have to store/upload the result and its current status before it
> shuts down?  If not, then I agree 60 seconds is a long time to wait.
> > I've tried adding the file to CONFIG_PROTECT in make.conf, to no avail.

No, it isn't that. All BOINC operations are local on the machine. Each project 
runs its calculations on its batch of downloaded data, then sends the result 
back. Each batch may take from many minutes to several days, even on a 
powerful machine.

The stop function has this, as Michael O. says:

local stop_timeout="SIGTERM/60/SIGTERM/30/SIGKILL/30"

It's just setting arbtrary times by which SGTERM should have stopped the 
program. In practice, the first SIGTERM is ignored, or otherwise fails, but the 
second one succeeds. Those periods are far too long here.

> The existing CONFIG_PROTECT in /usr/share/portage/config/make.globals ought
> to protect unwanted changes.  Have you inadvertently set
> CONFIG_PROTECT_MASK somewhere?

Make.conf includes settings of both CONFIG_PROTECT and CONFIG_PROTECT_MASK. 
It's assuming that init scripts should never be customised to suit local 
conditions, but that assumption is unhelpful in this case. And changing the 
order of those entries makes no difference either: the mask takes precedence.

-- 
Regards,
Peter.

Re: [gentoo-user] Protecting init.d files from auto-update

[Michael Orlitzky]

On Tue, 2025-01-14 at 16:28 +0000, Peter Humphrey wrote:
> 
> That's v helpful, Michael. Thanks.
> 
> Do you mind if I quote you in the bug report I send in?
> 

Nope, go ahead.

Re: [gentoo-user] Protecting init.d files from auto-update

[Peter Humphrey]

On Tuesday 14 January 2025 16:53:20 Greenwich Mean Time Michael Orlitzky 
wrote:
> On Tue, 2025-01-14 at 16:28 +0000, Peter Humphrey wrote:
> > That's v helpful, Michael. Thanks.
> > 
> > Do you mind if I quote you in the bug report I send in?
> 
> Nope, go ahead.

Thanks again. 

https://bugs.gentoo.org/948143

-- 
Regards,
Peter.

Re: [gentoo-user] Protecting init.d files from auto-update

[Peter Humphrey]

On Wednesday 15 January 2025 11:50:02 Greenwich Mean Time I wrote:

> https://bugs.gentoo.org/948143

That bug now has a patch, which proposes to move from sci-misc/boinc-7.24.1-r1 
to -r2. The scale of the changes proposed seems to me too big for such a minor 
revision bump, but more than that, it has several diffs against separate files, 
and I'm not /au-fait/ enough with patching to know what to do with them all.

Would anyone here like to have a go at it?

-- 
Regards,
Peter.

Re: [gentoo-user] Protecting init.d files from auto-update

[Alexis]

Peter Humphrey <peter@prh.myzen.co.uk> writes:

> On Wednesday 15 January 2025 11:50:02 Greenwich Mean Time I 
> wrote:
>
>> https://bugs.gentoo.org/948143
>
> That bug now has a patch, which proposes to move from
> sci-misc/boinc-7.24.1-r1
> to -r2. The scale of the changes proposed seems to me too big 
> for such
> a minor
> revision bump, but more than that, it has several diffs against
> separate files,
> and I'm not /au-fait/ enough with patching to know what to do 
> with
> them all.
>
> Would anyone here like to have a go at it?

Well, as the person who submitted that patch, i'd like to comment 
on this.

As some background:

* i've contributed a number of patches, such as to 
  gentoo-pipewire-launcher:

  https://bugs.gentoo.org/907891

* i currently have a new ebuild for the main repo awaiting 
  additional review from Sam, who hasn't been able to get to it 
  because he's constantly snowed under:

  https://bugs.gentoo.org/908431

* i maintain a few ebuilds in my overlay:

  https://sr.ht/~flexibeast/gentoo-overlay/

More generally, i'm a regular contributor to the Gentoo wiki; 
cf. https://wiki.gentoo.org/wiki/User:Flexibeast#Gentoo_wiki .

So:

* The move from -r1 to -r2 is required because a revision change 
  is required when there any changes to an ebuild, including to 
  Gentoo-provided files, that don't come from upstream. This in 
  turn requires a new ebuild file, which makes up a significant 
  amount of the patch.

* There are small changes to the boinc.conf and boinc.init files, 
  which i consider to be the minimum required to address the 
  suggestions that were made. Specifically:

  * The changes to boinc.conf remove the custom PID file variable, 
  replacing it with the standard $pidfile variable, and adds the 
  standard $retry variable.

  * The changes to boinc.init add default values for $pidvalue and 
  $retry in env_check(); change start() to use $pidfile instead of 
  the custom variable; move the call to env_check() into 
  stop_pre(); and change the stop() function to use the $pidfile 
  and $retry variables.

(Further to Michael Orlitzky's comment on the bug, it looks to me 
that the default stop() function doesn't use the $retry variable, 
so we need to provide a stop() function that does. i'll note this 
on the bug report shortly.)

i find your post here quite odd, discouraging, and an example of 
why i'm increasingly disinclined to devote so much time to 
volunteer ICT work, - that i would instead be better served by 
increasing my other volunteer work in other areas, where my 
experience is of people's gratitude rather than of 
entitlement. Rather than being appreciative of someone 
volunteering to take on the work, and rather than asking 
clarifying questions on the bug itself about what you don't 
understand, you've written a post on a public list effectively 
dismissing my work, assuming that it's fundamentally wrong. Okay 
then.


Alexis.

Re: [gentoo-user] Protecting init.d files from auto-update

[Peter Humphrey]

On Monday 20 January 2025 23:40:22 Greenwich Mean Time Alexis wrote:
> Peter Humphrey <peter@prh.myzen.co.uk> writes:
> > On Wednesday 15 January 2025 11:50:02 Greenwich Mean Time I
> > 
> > wrote:
> >> https://bugs.gentoo.org/948143
> > 
> > That bug now has a patch, which proposes to move from
> > sci-misc/boinc-7.24.1-r1 to -r2. The scale of the changes proposed seems
> > to me too big for such a minor revision bump, but more than that, it has
> > several diffs against separate files, and I'm not /au-fait/ enough with
> > patching to know what to do with them all.
> > 
> > Would anyone here like to have a go at it?
> 
> Well, as the person who submitted that patch, i'd like to comment
> on this.

--->8

> So:
> 
> * The move from -r1 to -r2 is required because a revision change
>   is required when there any changes to an ebuild, including to
>   Gentoo-provided files, that don't come from upstream. This in
>   turn requires a new ebuild file, which makes up a significant
>   amount of the patch.

You misunderstand. I'm saying that the version change should be bigger, not 
just from -r1 to -r2. Perhaps 7.24.2? 7.25?

> * There are small changes to the boinc.conf and boinc.init files,
>   which i consider to be the minimum required to address the
>   suggestions that were made.

OK.

>   Specifically:

--->8

> i find your post here quite odd, discouraging, and an example of
> why i'm increasingly disinclined to devote so much time to
> volunteer ICT work, - that i would instead be better served by
> increasing my other volunteer work in other areas, where my
> experience is of people's gratitude rather than of
> entitlement. Rather than being appreciative of someone
> volunteering to take on the work, and rather than asking
> clarifying questions on the bug itself about what you don't
> understand, you've written a post on a public list effectively
> dismissing my work, assuming that it's fundamentally wrong. Okay
> then.

Where on earth did you get that idea? I only said I couldn't see what to do, 
and asked for help with it.

-- 
Regards,
Peter.

Re: [gentoo-user] Protecting init.d files from auto-update

[Alexis]

Peter Humphrey <peter@prh.myzen.co.uk> writes:

> You misunderstand. I'm saying that the version change should be
> bigger, not just from -r1 to -r2. Perhaps 7.24.2? 7.25?

No, because those component numbers are specified by upstream - 
i.e. the BOINC project itself - not by Gentoo. But it's Gentoo 
that provides the OpenRC boinc.init and boinc.conf files - in the 
sci-misc/boinc/files folder of the Gentoo repository - not 
upstream. (If this were about files provided by upstream, rather 
than by Gentoo, an issue would need to have been raised with the 
BOINC project, not on the Gentoo bug tracker.) It's not Gentoo's 
place to change version numbers of the software that Gentoo 
packages, but Gentoo _can_ indicate revisions of how specific 
versions of the software are packaged. That's what numbers like 
-r1, -r2, etc. indicate.

> Where on earth did you get that idea? I only said I couldn't see 
> what
> to do, and asked for help with it.

You wrote, as i quoted in my previous email:

> The scale of the changes proposed seems to me too big for such a
> minor revision bump, but more than that, it has several diffs 
> against
> separate files, and I'm not /au-fait/ enough with patching to 
> know
> what to do with them all.
>
> Would anyone here like to have a go at it?

You didn't write:

> what to do with them all, and I need someone to explain it to
> me. Would anyone here like to have a go at it?

or

> what to do with them all. Would anyone here like to have a go at
> explaining to me what I need to do?

and so i read "it" as referring to the scale of the changes 
proposed being too big, and that you were asking for someone else 
to put together a patch - particularly because people who need 
help with something related to a bug report they've opened usually 
ask for that help on the bug report itself, rather than asking for 
help in some other venue.


Alexis.

Re: [gentoo-user] Protecting init.d files from auto-update

[Michael]

[-- Attachment #1: Type: text/plain, Size: 3145 bytes --]

On Tuesday 21 January 2025 11:59:11 Greenwich Mean Time Alexis wrote:
> Peter Humphrey <peter@prh.myzen.co.uk> writes:
> > You misunderstand. I'm saying that the version change should be
> > bigger, not just from -r1 to -r2. Perhaps 7.24.2? 7.25?
> 
> No, because those component numbers are specified by upstream -
> i.e. the BOINC project itself - not by Gentoo. But it's Gentoo
> that provides the OpenRC boinc.init and boinc.conf files - in the
> sci-misc/boinc/files folder of the Gentoo repository - not
> upstream. (If this were about files provided by upstream, rather
> than by Gentoo, an issue would need to have been raised with the
> BOINC project, not on the Gentoo bug tracker.) It's not Gentoo's
> place to change version numbers of the software that Gentoo
> packages, but Gentoo _can_ indicate revisions of how specific
> versions of the software are packaged. That's what numbers like
> -r1, -r2, etc. indicate.
> 
> > Where on earth did you get that idea? I only said I couldn't see
> > what
> > to do, and asked for help with it.
> 
> You wrote, as i quoted in my previous email:
> > The scale of the changes proposed seems to me too big for such a
> > minor revision bump, but more than that, it has several diffs
> > against
> > separate files, and I'm not /au-fait/ enough with patching to
> > know
> > what to do with them all.
> > 
> > Would anyone here like to have a go at it?
> 
> You didn't write:
> > what to do with them all, and I need someone to explain it to
> > me. Would anyone here like to have a go at it?
> 
> or
> 
> > what to do with them all. Would anyone here like to have a go at
> > explaining to me what I need to do?
> 
> and so i read "it" as referring to the scale of the changes
> proposed being too big, and that you were asking for someone else
> to put together a patch - particularly because people who need
> help with something related to a bug report they've opened usually
> ask for that help on the bug report itself, rather than asking for
> help in some other venue.
> 
> 
> Alexis.

I didn't read Peter's message as being (intentionally) offensive, or 
questioning the quality of your contribution, but raising points he did not 
understand fully and asking for help.  I for one tend to avoid asking for 
detailed explanation and guidance in bug reports, because it could be seen as 
creating unnecessary noise and potentially taking up dev/maintainers' time for 
simpler issues for which I could hopefully find a solution offline.  Since 
gentoo-user is a user rather than a dev mailing list, it allows for more noisy 
discussions and also helps the rest of us learn things we haven't come across 
in our travels.

I don't use BOINC and haven't sync'ed portage to see what version(s) may be 
available, but isn't applying testing patches a matter of adding them in /etc/
portage/patches/ as explained here:

https://wiki.gentoo.org/wiki//etc/portage/patches

Or if you're scratching your own ebuild, by adding them in the ebuild files/ 
directory and calling them in src_prepare()?  Like this:

https://devmanual.gentoo.org/ebuild-writing/functions/src_prepare/eapply/
index.html



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Protecting init.d files from auto-update

[Peter Humphrey]

On Monday 20 January 2025 13:24:20 Greenwich Mean Time Peter Humphrey wrote:
> On Wednesday 15 January 2025 11:50:02 Greenwich Mean Time I wrote:
> > https://bugs.gentoo.org/948143
> 
> That bug now has a patch, which proposes to move from
> sci-misc/boinc-7.24.1-r1 to -r2. The scale of the changes proposed seems to
> me too big for such a minor revision bump, but more than that, it has
> several diffs against separate files, and I'm not /au-fait/ enough with
> patching to know what to do with them all.
> 
> Would anyone here like to have a go at it?

Well, I've learned a few things today, though I imagine I'll have forgotten 
them by tomorrow.  :-(

I did my best to separate what Alexis contributed into its target files, and I 
think it's now working from a local repo. At least I can --sync and --update 
boinc to -r2 without errors.

However - stopping boinc still takes 60 seconds, with the differencec that I 
don't now see the trail of dots to show me how much longer I have to wait.

Is that period hard-coded into the start/stop mechanism of openrc?

-- 
Regards,
Peter.

Re: [gentoo-user] Protecting init.d files from auto-update

[Peter Humphrey]

On Tuesday 21 January 2025 11:59:11 Greenwich Mean Time Alexis wrote:
> Peter Humphrey <peter@prh.myzen.co.uk> writes:
> > You misunderstand. I'm saying that the version change should be
> > bigger, not just from -r1 to -r2. Perhaps 7.24.2? 7.25?
> 
> No, because those component numbers are specified by upstream -
> i.e. the BOINC project itself - not by Gentoo. But it's Gentoo
> that provides the OpenRC boinc.init and boinc.conf files - in the
> sci-misc/boinc/files folder of the Gentoo repository - not
> upstream

Point taken.

I have now (I think) applied your diffs, manually, and I'll report my 
experiences.

-- 
Regards,
Peter.

Re: [gentoo-user] Protecting init.d files from auto-update

[Alexis]

Peter Humphrey <peter@prh.myzen.co.uk> writes:

> However - stopping boinc still takes 60 seconds, with the 
> differencec
> that I don't now see the trail of dots to show me how much 
> longer I
> have to wait.
>
> Is that period hard-coded into the start/stop mechanism of 
> openrc?

i assume that might be a result of the default value for the 
$retry variable being "SIGTERM/60/SIGTERM/30/SIGKILL/30"; refer to 
line 48 of boinc.init, inside the env_check() function, which sets 
$retry to that value if it's not otherwise specified. The man page 
for openrc-run(8) says:

> retry    Retry schedule to use when stopping the daemon. It can
>          either be a timeout in seconds or multiple
>          signal/timeout pairs (like SIGTERM/5).

but doesn't explain what it means to have two different pairs for 
the same signal, as above. (Nor does 
https://github.com/OpenRC/openrc/blob/master/service-script-guide.md 
seem to have any relevant information in this regard.)

If you set `retry` in boinc.conf to, say, "SIGTERM/10/SIGKILL/20", 
for a 10-second timeout in response to a SIGTERM signal and a 
20-second timeout in response to a SIGKILL signal, does that 
reduce the stopping time? If so, to what duration? Hopefully 
setting different timeout periods for different signals will mean 
we can deduce what signals are being received from the stopping 
duration. 

Even if it does, it's a concern that the timeout limit is being 
reached; it suggests that the boinc service isn't shutting down 
gracefully in response to a SIGTERM, even after 60 seconds, 
resulting in it needing to be forcefully terminated.


Alexis.

Re: [gentoo-user] Protecting init.d files from auto-update

[Peter Humphrey]

On Friday 31 January 2025 02:53:06 Greenwich Mean Time Alexis wrote:

--->8

> If you set `retry` in boinc.conf to, say, "SIGTERM/10/SIGKILL/20",
> for a 10-second timeout in response to a SIGTERM signal and a
> 20-second timeout in response to a SIGKILL signal, does that
> reduce the stopping time? If so, to what duration? Hopefully
> setting different timeout periods for different signals will mean
> we can deduce what signals are being received from the stopping
> duration.

In the -r1 version, with SIGTERM/60/SIGTERM/30/SIGKILL/30, BOINC activity 
stopped immediately*, but control wasn't returned to me until 60s later. That 
is, the first SIGTERM was obeyed but the system didn't become aware of it until 
it sent the second SIGTERM. So, apparently, the boinc code needed a second 
prod to report back.

Today I set retry="SIGTERM/4/SIGTERM/3/SIGKILL/3" on this machine, which only 
ever runs one BOINC task at a time. That process stopped straight away, but 
control didn't return to me until 7s after the 'boinc stop' command. That is, 
the first SIGTERM was obeyed, but this time the system didn't know until it 
sent the SIGKILL command, having apparently not seen any effect from the second 
SIGTERM. Does that mean the code needs longer between signals?

To test that I changed the intervals to SIGTERM/8/SIGTERM/6/SIGKILL/4, then 
started and stopped boinc. Its Asteroids@Home process stopped within about 6s, 
but control didn't return to me until 14s.

I deduce that the boinc management code is not reacting to signals properly.

> Even if it does, it's a concern that the timeout limit is being
> reached; it suggests that the boinc service isn't shutting down
> gracefully in response to a SIGTERM, even after 60 seconds,
> resulting in it needing to be forcefully terminated.

Well, it does seem so now, but until I started all this it was stopping on the 
second SIGTERM. I could spend hours on establishing definitely what's going on, 
but I hope it doesn't come to that - for one thing, I only have the two 
machines to test on: an i5 NUC and a Ryzen M9. At the moment I'm content that 
my settings are not going to be overwritten with every upgrade of sci-misc/
boinc.

Incidentally, I've been seeing "A new version of BOINC is available (8.0.2)." 
for some months in messages from the boinc manager.

*  'tail -f /var/lib/boinc/stdoutdae.txt' showed boinc exiting instantly, and 
gkrellm showed CPU use dropping to zero. It's hard to be definite about what   
/bin/top shows, as it only updates every 3s, gkrellm every 2s. That caveat 
applies to all the times I've mentioned in this thread.

-- 
Regards,
Peter.

Re: [gentoo-user] Protecting init.d files from auto-update

[Peter Humphrey]

On Friday 31 January 2025 14:24:15 Greenwich Mean Time I wrote:

> *  'tail -f /var/lib/boinc/stdoutdae.txt' showed boinc exiting instantly,
> and gkrellm showed CPU use dropping to zero. It's hard to be definite about
> what /bin/top shows, as it only updates every 3s, gkrellm every 2s. That
> caveat applies to all the times I've mentioned in this thread.

That should have been "gkrellm every second."

-- 
Regards,
Peter.