Exclusive apps cannot be specified with absolute path

Message boards : Questions and problems : Exclusive apps cannot be specified with absolute path
Message board moderation

To post messages, you must log in.

AuthorMessage
Peter Humphrey

Send message
Joined: 25 Nov 13
Posts: 30
United Kingdom
Message 88152 - Posted: 23 Sep 2018, 9:58:52 UTC

On this Gentoo Linux box, Chromium (the OS version of Google Chrome) is compiled using /usr/lib/llvm/7/bin/x86_64-pc-linux-gnu-clang++ . This is not under /usr/bin, but I'd like BOINC to be suspended while that compiler is running. Chrome takes well over an hour to compile here, even with BOINC suspended manually.
Please allow me to include this entry in cc_config.xml and have it obeyed:
<exclusive_app>/usr/lib/llvm/7/bin/x86_64-pc-linux-gnu-clang++</exclusive_app>
Thank you.
ID: 88152 · Report as offensive
Juha
Volunteer developer
Volunteer tester
Help desk expert

Send message
Joined: 20 Nov 12
Posts: 801
Finland
Message 88154 - Posted: 23 Sep 2018, 20:40:07 UTC - in response to Message 88152.  

What exactly does BOINC say if you put that entry in cc_config.xml? Are you editing the config file manually or are you using Manager for it?
ID: 88154 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15477
Netherlands
Message 88156 - Posted: 24 Sep 2018, 7:14:58 UTC

I also wonder why you can't just use x86_64-pc-linux-gnu-clang++ as the executable's name. The way that BOINC checks whether these exclusive apps are active is by checking whether they are in the operating system's active memory. If they are and they are executables, act upon them.
ID: 88156 · Report as offensive
Peter Humphrey

Send message
Joined: 25 Nov 13
Posts: 30
United Kingdom
Message 88157 - Posted: 24 Sep 2018, 7:25:25 UTC - in response to Message 88154.  

I can't use the manager because it's preset to /usr/bin, so I edited the file by hand. When I hit the Read Config Files option, stdoutdae.txt shows "Config: don't compute while /usr/lib/llvm/7/bin/x86_64-pc-linux-gnu-clang++ is running", but when clang++ runs, BOINC ignores it.

It does sometimes suspend on CPU Busy if enough instances of clang++ are running. Usually not, though, because most of the "busyness" is due to BOINC itself, so clang++ is crowded out and relegated to single-digit percentages of CPU time.
ID: 88157 · Report as offensive
Peter Humphrey

Send message
Joined: 25 Nov 13
Posts: 30
United Kingdom
Message 88158 - Posted: 24 Sep 2018, 8:08:38 UTC - in response to Message 88156.  

I tried that, and saw the same result.
ID: 88158 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15477
Netherlands
Message 88159 - Posted: 24 Sep 2018, 8:21:14 UTC - in response to Message 88158.  

Can you check one thing?
Make sure you have exited the BOINC client (e.g. boinccmd --quit)
Open client_state.xml in your favorite editor (careful, don't add anything, or when you do and are asked to save changes, click Cancel) and scroll to the bottom. What does it say for user_run_request? It needs to be 2 (based on preferences). If it's 1, it'll run always and ignore any set preferences, including the exclusive apps. In that case change it to 2 and save, then restart the BOINC client.
ID: 88159 · Report as offensive
Peter Humphrey

Send message
Joined: 25 Nov 13
Posts: 30
United Kingdom
Message 88160 - Posted: 24 Sep 2018, 15:06:52 UTC - in response to Message 88159.  

Yes, that's confirmed:
$ grep user_run_request ./boinc/client_state.xml
<user_run_request>2</user_run_request>

Besides, the other exclusive apps are detected just fine, as specified here:

$ grep exclusive ./boinc/cc_config.xml
<exclusive_app>cc1</exclusive_app>
<exclusive_app>cc1plus</exclusive_app>
<exclusive_app>cmake</exclusive_app>
<exclusive_app>rustc</exclusive_app>
<exclusive_app>/usr/lib/llvm/7/bin/x86_64-pc-linux-gnu-clang++</exclusive_app>

One other thing: I run the BOINC client from its own partition mounted under my home directory. All the files are owned by me, having been set that way by the startup script /etc/init.d/boinc.

$ grep prh /etc/fstab
/dev/nvme0n1p7 /home/prh/common ext4 relatime 1 3
/dev/nvme0n1p16 /home/prh/.VirtualBox ext4 relatime 1 3
/dev/nvme0n1p17 /home/prh/boinc ext4 relatime 1 3
ID: 88160 · Report as offensive
Juha
Volunteer developer
Volunteer tester
Help desk expert

Send message
Joined: 20 Nov 12
Posts: 801
Finland
Message 88248 - Posted: 27 Sep 2018, 18:53:50 UTC - in response to Message 88160.  

Please do a bit testing for me.

Run clang and examine the various files in /proc/pid-of-clang/. You'll probably find the program name in the files in different forms. Try every form you find as <exclusive_app>. I suspect one of the forms is shorter than the full name and BOINC is using that one.

You mentioned that BOINC prevents clang from using all the CPU power it could use. This could be happen if the build is running at idle priority level. Is that what's happening and if it is then is it intentional?
ID: 88248 · Report as offensive
Peter Humphrey

Send message
Joined: 25 Nov 13
Posts: 30
United Kingdom
Message 88268 - Posted: 29 Sep 2018, 16:22:59 UTC - in response to Message 88248.  

It's tricky catching a /proc/<pid> while it's still active - there can be 20-odd of them at a time, and they only live for as long as it takes to compile their unit and then die. When I do catch one there are 24 files under the /proc/<pid>, one of which is named "exe" and is a symbolic link to /usr/lib/llvm/7/bin/clang-7. I saw several of these, so I assume that's where the compiler is expected to live.

Putting that into cc_config.xml made no difference in suspending BOINC.

I had PORTAGE_NICENESS=16, which should be passed to all daughter processes in the compilation. As far as I know, BOINC runs at 23 and should give way politely. It didn't though, so now I've set portage niceness to 3 and reduced the "suspend when CPU load is above ..." from 20 to 10, and clang is allowed to run. It's a workaround, though, and may not suit other loading situations.

Let me know if I can try something else.
ID: 88268 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 5077
United Kingdom
Message 88269 - Posted: 29 Sep 2018, 17:23:49 UTC - in response to Message 88268.  

As far as I know, BOINC runs at 23 and should give way politely.
BOINC itself probably isn't your problem. It uses very few computer resurces - 14 minutes of CPU time in the 11 days since this computer was last rebooted.

Resource contention is more likely to be caused by the project science apps, which run at up to 100% CPU usage given half a chance. But they should, also, run at very low priority and give way politely, as you say. It might be worth probing their behaviour next time the problem re-surfaces.
ID: 88269 · Report as offensive
Juha
Volunteer developer
Volunteer tester
Help desk expert

Send message
Joined: 20 Nov 12
Posts: 801
Finland
Message 88270 - Posted: 29 Sep 2018, 19:23:21 UTC - in response to Message 88268.  

BOINC not playing nice may be caused by Linux kernel autogrouping feature. See sched(7). I have autogrouping disabled on my Linux box because it didn't play nicely with BOINC. I can't remember the details, it's too long ago when I made that change. I thought it was kernel bug but that man page makes it sound like that's how it's supposed to work. (Puns not intended.)

I'll go and check the source about the exclusive apps.
ID: 88270 · Report as offensive
Juha
Volunteer developer
Volunteer tester
Help desk expert

Send message
Joined: 20 Nov 12
Posts: 801
Finland
Message 88283 - Posted: 1 Oct 2018, 20:45:17 UTC - in response to Message 88152.  

Try using "x86_64-pc-linux" plus or minus a character as <exclusive_app>. BOINC gets the program name from /proc/pid/stat which records only 15 characters of the name.
ID: 88283 · Report as offensive
Peter Humphrey

Send message
Joined: 25 Nov 13
Posts: 30
United Kingdom
Message 88299 - Posted: 3 Oct 2018, 16:04:08 UTC - in response to Message 88283.  

Now I am really mystified. I changed cc_config.xml thus:

$ grep exclusive boinc/cc_config.xml
<exclusive_app>cc1</exclusive_app>
<exclusive_app>cc1plus</exclusive_app>
<exclusive_app>cmake</exclusive_app>
<exclusive_app>rustc</exclusive_app>
<exclusive_app>x86_64-pc-linux</exclusive_app>
<exclusive_app>/usr/lib/llvm/7/bin/clang-7</exclusive_app>
<exclusive_app>/usr/lib/llvm/7/bin/x86_64-pc-linux-gnu-clang++</exclusive_app>

(I hope I can take those last two out now.)

Now boincmgr correctly reports that it's suspended because an exclusive app is running.

But that's where I started from! I had <exclusive_app>x86_64-pc-linux</exclusive_app> in there originally and it was not being respected, which is why I started this topic. I can only suppose I had a typo, except that copy-paste just about eliminates that possibility.

I can only say I'll keep an eye on it, and hope no-one's spent too much time here.
ID: 88299 · Report as offensive
Profile Kadinzonecom

Send message
Joined: 15 Oct 18
Posts: 1
Turkey
Message 88451 - Posted: 15 Oct 2018, 9:12:31 UTC

I fixed. Thank you to everyone who contributed.
ID: 88451 · Report as offensive

Message boards : Questions and problems : Exclusive apps cannot be specified with absolute path

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.