| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 35 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 29:23:11 |
| Calls: | 322 |
| Calls today: | 1 |
| Files: | 959 |
| Messages: | 81,834 |
| Posted today: | 3 |
https://bugs.gentoo.org/948143
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?
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.
The existing CONFIG_PROTECT in /usr/share/portage/config/make.globals ought to protect unwanted changes. Have you inadvertently set
CONFIG_PROTECT_MASK somewhere?
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.
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.
* 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:
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.
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.
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.
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?
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
* '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.
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.
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.