Hello,
I am running boinc 7.22.1 in Arch linux, running tasks from Einstein@Home.

My boinc-client is running as a systemd service. Whenever I reboot or shutdown my system, this systemd message appears: "A stop job is running for Berkeley Open Infrastructure Network Computing Client", along with a timer that counts down 60 seconds before the shutdown continues.

If I enter "systemctl stop boinc-client.service" in a terminal, I don't see the message or the timer, but the command blocks for 60 seconds. However, if I have the Boinc Manager open on the Tasks tab when I enter the stop command, the tasks all disappear immediately.

I have mitigated this by setting "TimeoutStopSec=10" in the systemd boinc-client.service unit file, but I would like to get rid of this timeout. Has anyone else seen anything like this?

BOINC (internally) has two modes for stopping the client;

The "polite" one, where it issues a 'request' to the client to shut itself down. That allows any exit dialogs to be shown, all output files to be flushed to disk and closed, log files likewise, and so on. Only then does the client report back to the calling program that all is complete, and that it's safe to continue with the closedown without risk of data loss or damage.

The other mode is much ruder (it has been described by a researcher/system admin as "terminate with extreme prejudice"). It forces the client to stop immediately, without regard to what it's working on. I would keep this one for emergencies only.

Having said that, it's unusual for the 'polite' call to delay things by as much as a minute. It might be a 'feature' of a science project you're running (aka 'bug'): while it's closing down, the client goes through a similar call-and-response with each of the science apps it's started. Boinc will only shut itself down after every science app has reported a safe closedown. If just one of the science apps is badly behaved, and doesn't hear the call to close, that might have the effect you're describing.

I see this on a few projects for cpu apps. I have to wait approx. 15-30 seconds for all the universe tasks to finish up in the system monitor and flush out after exiting the client. Then I can feel confident all the apps and tasks have written out all the result files.

Thank you for the responses. I'm not sure if this proves anything, but for troubleshooting, if I first remove that "TimeoutStopSec" setting from the boinc unit file, then, in the boinc manager, do Activity->Suspend, and then issue the SYSTEMCTL STOP command, it still blocks for 60 sec.

I would like to look at the boinc logs after the systemctl stop to see it they show anything useful, but in the boinc manager, Tools->Event Log is grayed out after the systemctl stop.

I only recently started running Arch linux. For years, in my previous distro (gentoo), I was running boinc Einstein@Home tasks, but wasn't controlling the client with Systemd. I'm not sure now how the boinc-client was terminated when I shut down my PC, but I never noticed any delay. Maybe the boinc tasks were terminated "with prejudice".

stdoutdae.txt will let you see the information that would be in the event log. I open it with the kate text editor and have it auto-reload. I don't know which other text editors will do that. I have been using it recently when the event log was refusing to display with my Windows client running under WINE.

If he's using systemd, the old logs will be in the system journal, not a text file.

Like many Linux functions, there's a hugely complex set of options, too many to list here.

I refer to somewhere like https://man7.org/linux/man-pages/man1/journalctl.1.html - you need to filter it down to the boinc unit, and choose a tight time-frame. But it's all there.

If he's using systemd, the old logs will be in the system journal, not a text file.

I have both on my Linux machine. (That is on both the native Linux client and the Windows one running under WINE.)

I have both on my Linux machine. (That is on both the native Linux client and the Windows one running under WINE.)

Just wondering if that is anything to do with compiling my own client rather than using the packaged one?

I have both on my Linux machine. (That is on both the native Linux client and the Windows one running under WINE.)

Just wondering if that is anything to do with compiling my own client rather than using the packaged one?

Quite likely. My initial installation/setup was done from Gianfanco's PPA, which I think sets up the full package of hooks into the host operating system. I've done binary upgrades since then, but just by replacing individual files - not fiddling with the package structure.

Sorry so late responding. Below is my boinc systemd log from shutting down yesterday. I have the unit timeout set to 10 seconds instead of 60 seconds. I don't see anything useful here, but I notice in the boinc manager Event Log Options, there are a lot of log messages I could enable if they would help here (currently I have the defaults of file_xfer, task, and sched_ops enabled)

Jul 28 21:29:21 officepc systemd[1]: Stopping Berkeley Open Infrastructure Network Computing Client...
Jul 28 21:29:21 officepc boinc[776]: 28-Jul-2023 21:29:21 [---] Received signal 15
Jul 28 21:29:22 officepc boinc[776]: 28-Jul-2023 21:29:22 [---] Exiting
Jul 28 21:29:31 officepc systemd[1]: boinc-client.service: State 'stop-sigterm' timed out. Killing.
Jul 28 21:29:31 officepc systemd[1]: boinc-client.service: Killing process 776 (boinc) with signal SIGKILL.
Jul 28 21:29:31 officepc systemd[1]: boinc-client.service: Killing process 1873 (hsgamma_FGRP5_1) with signal SIGKILL.
Jul 28 21:29:31 officepc systemd[1]: boinc-client.service: Killing process 1874 (hsgamma_FGRP5_1) with signal SIGKILL.
Jul 28 21:29:31 officepc systemd[1]: boinc-client.service: Killing process 1875 (hsgamma_FGRP5_1) with signal SIGKILL.
Jul 28 21:29:31 officepc systemd[1]: boinc-client.service: Killing process 1876 (hsgamma_FGRP5_1) with signal SIGKILL.
Jul 28 21:29:31 officepc systemd[1]: boinc-client.service: Killing process 1877 (hsgamma_FGRP5_1) with signal SIGKILL.
Jul 28 21:29:31 officepc systemd[1]: boinc-client.service: Killing process 1878 (hsgamma_FGRP5_1) with signal SIGKILL.
Jul 28 21:29:31 officepc systemd[1]: boinc-client.service: Main process exited, code=killed, status=9/KILL
Jul 28 21:29:31 officepc systemd[1]: boinc-client.service: Failed with result 'timeout'.
Jul 28 21:29:31 officepc systemd[1]: Stopped Berkeley Open Infrastructure Network Computing Client.
Jul 28 21:29:31 officepc systemd[1]: boinc-client.service: Consumed 2h 59min 12.546s CPU time.

To me, that looks as if systemd tries first with sigterm - I think that's the 'polite' one - and waits 10 seconds. But BOINC doesn't respond, so it moves on to the aggressive one - sigkill.

Is hsgamma_FGRP5_1 one of the Einstein@Home applications? They're usually pretty well behaved. It might be worth trying again with a longer delay - see if any more of the process becomes visible in the log.

Yes, those are Einstein@Home. When I first started running boinc on this system, a couple of weeks ago, that was a 60 second delay instead of 10 seconds. I figured out I could set "TimeoutStopSec=10" in the systemd unit to at least reduce the delay at shutdown/reboot.

If he's using systemd, the old logs will be in the system journal, not a text file.

Boinc still logs to stdoutdae.txt

I would like to look at the boinc logs after the systemctl stop to see it they show anything useful, but in the boinc manager, Tools->Event Log is grayed out after the systemctl stop.

I would like to look at the boinc logs after the systemctl stop to see it they show anything useful, but in the boinc manager, Tools->Event Log is grayed out after the systemctl stop.

You can look at the 'back numbers' from the Event Log with a command like:

journalctl -b --unit=boinc-client

As it stands, that will go back as the last reboot and show you everything since then - you may want to redirect the output to a file. Journalctl, like all Linux commands, has an enormous number of other options, but that should be enough to get you started.