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

[Peter Humphrey <peter@prh.myzen.co.uk>]

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.