So far as I know, NONE of the various project executables, graphics programs, wrappers etc. are digitally signed, and in the Windows environment, this is a problem.
They're all digitally signed. See http://boinc.berkeley.edu/trac/wiki/CertSig for info on that. You can see your public key per project in the client_state.xml file, while you can see per application what its md5_checksum is.
So far as I know, NONE of the various project executables, graphics programs, wrappers etc. are digitally signed, and in the Windows environment, this is a problem.
They're all digitally signed. See http://boinc.berkeley.edu/trac/wiki/CertSig for info on that. You can see your public key per project in the client_state.xml file, while you can see per application what its md5_checksum is.
Yes, the system works well (so far), as far as the BOINC client is concerned. But the regime described in the wiki is strictly intra-BOINC. I guess it depends on your definition of "digitally signed." As with so many things in life, that depends on your point of view. To the BOINC client that can read & understand client_state.xml, yes it's signed; to the rented security guard who can't, not so much. He's not invited into that "chain of trust." He knows only that his customer owns a building in a bad neighborhood, and BOINC is just one of the tenants. Kaspersky takes each executable from whatever source on its own merits--he doesn't care about trusted sources, or what client_state.xml says. If the app doesn't come to the lobby with a valid digital certificate attached, it is designated unsigned and gets a threat assessment. If that goes well, it gets access to system resources, albeit on a leash. If the assessment goes badly, it's blocked until the landlord says otherwise.
I should mention that (also from personal experience) ZoneAlarm Security Suite has nearly identical problems with a small number of these project apps, unless you run it permanently in Learn mode. Which is a bit like running with scissors.
Execution is held in abeyance and an alert appears on the screen asking the user to decide whether to allow execution or not. The problem is, the alert is only posted for a few minutes after which the application is automatically blocked.
Thanks a lot for your explanation!
Do you have an idea how this "holding" and then "blocking" is done technically? I'm looking for a way to make the BOINC Core Client aware of apps being treated that way.
[edit] Does anyone has an idea why this only seems to have such a bad effect when throtteling is enabled? [/edit]
[edit] Does anyone has an idea why this only seems to have such a bad effect when throtteling is enabled? [/edit]
The exit problem happens when BOINC can't acquire a lockfile, as it's in use by another process. This other process is usually the anti-virus software doing active scans of all files in the BOINC Data directory and sub-directories, while since it is running in a normal to high priority it will be locking files in place, overriding BOINC's access to them. When locked, BOINC can't read them or update them.
The throttling that BOINC uses is not done through any API, such as 3rd party applications do. It's simply done by suspending the science application for a (couple of) second(s) and resuming it for a (couple of) second(s) more. So in essence, BOINC is continuously running the application, even when throttling. Anything from the outside at that time interfering (the lockfile thing again for instance) will give trouble.
Well the error came back. I checked and another entry had been added in the application control for Einstein. I fixed that entry but it looked like the error is still there this time. Maybe there is another entry I missed but its getting aggravating track down these issues. I did set Kaspersky up to email me when it made changes and I'll do that on the second machine that has it installed sometime later today.
I guess its possible that this time the problem was something else but I don't think so.
If the issue continues today I'll cut application control off on that machine to see what happens.
To the guy who likes Kaspersky - I understand about security but I'm a single home user with four machines currently running just because. I have redundant back ups and am perfectly capable of formatting a hard drive and reloading a system if something happens. I have only one machine that contains anything that might cause me any aggravation if I lose it and even that is easy to restore. For me Kaspersky is overkill. In over 20 years on PC's I've only managed to get three viruses and only one of those caused me to have to reformat. My son on the other hand seems to be good at finding them so maybe for some users its worth it. For me its just made doing some things harder.
Thanks I just recently put a new anti-virus program on the machine. That must be it. I'll try excluding einstein from scans
We have been looking for the cause of this error (on and off) for months now.
(...)
BM
Maybe I found another reason for this error. The process which used the lockfile was Einstein@home itself.
I use to set my system in energy save mode when I don't use it. After waking up the system I found the messages "exited with zero status but no finished file" in BOINC. After finding the message "Can't acquire lockfile" in the stderr.txt in the folder of the slot I tried to delete the lockfile, so Einstein could create a new one. I couldn't because it was in use. I stopped working of BOINC via Control - Stop (in German Menü Steuerung - Anhalten) and tried it again. File in use again.
Now I searched the Windows task list for a process which could use the lockfile and to my surprise I found a Einstein@home process still running. I killed the process, restarted BOINC and everything was fine.
I had this situation more than once. I assume that BOINC couldn't stop all processes when Windows was suspending work but restarted all work units after Windows resume operation. I haven't had the problem in the recent weeks. It only occured as I rejoined BOINC a month ago when Einstein@home was the only project I was calculating for. Maybe a reason could be that Einstein@home could only use CPU at that time, my graphic driver was too old to use CUDA at first. So at that time there were two CPU work units running parallel.
BTW I'm running Windows Vista 32bit and my anti-virus program is GDATA.
I stopped working of BOINC via Control - Stop (in German Menü Steuerung - Anhalten) and tried it again. File in use again.
That would be Activity - Suspend :-)
Suspended tasks are only removed from task manager if the computing preferences are set to
Leave applications in memory while suspended? no
(suspended applications will consume swap space if 'yes')
Though additionally started tasks should use another slot directory and thus the lockfile problem wouldn't occur.
Quote:
Now I searched the Windows task list for a process which could use the lockfile and to my surprise I found an Einstein@home process still running.
To make sure that BOINC can't stop those processes you'd have to use
Advanced - Shut down connected client... [Extras - Herunterfahren des aktuell verbundenen Client... (falscher Genitiv ;-)]
But, as said before, you are probably right, as different "normally started" tasks shouldn't share a lockfile.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
Suspended tasks are only removed from task manager if the computing preferences are set to
Leave applications in memory while suspended? no
(suspended applications will consume swap space if 'yes')
Yes, my computing preferences were set this way.
Sorry, that I wasn't precise enough. To make it quite clear:
I had two active Einstein work units.
After resuming Windows operation there were four Einstein processes in the task list.
After supending activity in BOINC I found one Einstein process.
After killing it zero ;-)
Again starting activity in BOINC it had three processes in the task list (why three for two work units, no idea. What a pity I didn't write down the task names)
After supending activity in BOINC I found one Einstein process.
Okay, that shouldn't happen with your preferences set up as they are.
Quote:
Again starting activity in BOINC it had three processes in the task list (why three for two work units, no idea. What a pity I didn't write down the task names)
You'll have two processes for each S5R6 task and one process for each ABP1 task, so the count of three is easily explained.
The two processes for S5R6 are the "switcher" program (einstein_S5R6_3.01_windows_intelx86.exe), which selects the executable with the best-fitting optimisation for your processor, and the selected executable itself (einstein_S5R6_3.01_windows_intelx86_X.exe, with X being 0, 1 or 2 respectively).
The ABP1 executable (currently) is called einsteinbinary_ABP1_3.12_windows_intelx86.exe
If you intend to keep letting your computers go to sleep mode, you should consider setting the following preference accordingly:
Suspend work if no mouse/keyboard activity in last --- minutes
(Needed to enter low-power mode on some computers)
Enforced by version 5.10.14+
[edit]...if they hibernate automatically. If you enter sleep mode manually, you'll have to suspend BOINC manually as well.[/edit]
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
Now I searched the Windows task list for a process which could use the lockfile and to my surprise I found a Einstein@home process still running. I killed the process, restarted BOINC and everything was fine.
Do you happen to recall the name of the process? In particular whether it was of the form "einsteinbinary_*", "einstein_*_windows_intelx86.exe", "einstein_*_windows_intelx86_2.exe" or "einstein_*_windows_intelx86_S5R6sse2.exe"?
RE: So far as I know, NONE
)
They're all digitally signed. See http://boinc.berkeley.edu/trac/wiki/CertSig for info on that. You can see your public key per project in the client_state.xml file, while you can see per application what its md5_checksum is.
RE: RE: So far as I know,
)
Yes, the system works well (so far), as far as the BOINC client is concerned. But the regime described in the wiki is strictly intra-BOINC. I guess it depends on your definition of "digitally signed." As with so many things in life, that depends on your point of view. To the BOINC client that can read & understand client_state.xml, yes it's signed; to the rented security guard who can't, not so much. He's not invited into that "chain of trust." He knows only that his customer owns a building in a bad neighborhood, and BOINC is just one of the tenants. Kaspersky takes each executable from whatever source on its own merits--he doesn't care about trusted sources, or what client_state.xml says. If the app doesn't come to the lobby with a valid digital certificate attached, it is designated unsigned and gets a threat assessment. If that goes well, it gets access to system resources, albeit on a leash. If the assessment goes badly, it's blocked until the landlord says otherwise.
I should mention that (also from personal experience) ZoneAlarm Security Suite has nearly identical problems with a small number of these project apps, unless you run it permanently in Learn mode. Which is a bit like running with scissors.
B/W,
J. Whalen RMCM(SS) USN Ret.
Best wishes :)
RE: Execution is held in
)
Thanks a lot for your explanation!
Do you have an idea how this "holding" and then "blocking" is done technically? I'm looking for a way to make the BOINC Core Client aware of apps being treated that way.
[edit] Does anyone has an idea why this only seems to have such a bad effect when throtteling is enabled? [/edit]
BM
BM
RE: [edit] Does anyone has
)
The exit problem happens when BOINC can't acquire a lockfile, as it's in use by another process. This other process is usually the anti-virus software doing active scans of all files in the BOINC Data directory and sub-directories, while since it is running in a normal to high priority it will be locking files in place, overriding BOINC's access to them. When locked, BOINC can't read them or update them.
The throttling that BOINC uses is not done through any API, such as 3rd party applications do. It's simply done by suspending the science application for a (couple of) second(s) and resuming it for a (couple of) second(s) more. So in essence, BOINC is continuously running the application, even when throttling. Anything from the outside at that time interfering (the lockfile thing again for instance) will give trouble.
Well the error came back. I
)
Well the error came back. I checked and another entry had been added in the application control for Einstein. I fixed that entry but it looked like the error is still there this time. Maybe there is another entry I missed but its getting aggravating track down these issues. I did set Kaspersky up to email me when it made changes and I'll do that on the second machine that has it installed sometime later today.
I guess its possible that this time the problem was something else but I don't think so.
If the issue continues today I'll cut application control off on that machine to see what happens.
To the guy who likes Kaspersky - I understand about security but I'm a single home user with four machines currently running just because. I have redundant back ups and am perfectly capable of formatting a hard drive and reloading a system if something happens. I have only one machine that contains anything that might cause me any aggravation if I lose it and even that is easy to restore. For me Kaspersky is overkill. In over 20 years on PC's I've only managed to get three viruses and only one of those caused me to have to reformat. My son on the other hand seems to be good at finding them so maybe for some users its worth it. For me its just made doing some things harder.
RE: RE: Thanks I just
)
Maybe I found another reason for this error. The process which used the lockfile was Einstein@home itself.
I use to set my system in energy save mode when I don't use it. After waking up the system I found the messages "exited with zero status but no finished file" in BOINC. After finding the message "Can't acquire lockfile" in the stderr.txt in the folder of the slot I tried to delete the lockfile, so Einstein could create a new one. I couldn't because it was in use. I stopped working of BOINC via Control - Stop (in German Menü Steuerung - Anhalten) and tried it again. File in use again.
Now I searched the Windows task list for a process which could use the lockfile and to my surprise I found a Einstein@home process still running. I killed the process, restarted BOINC and everything was fine.
I had this situation more than once. I assume that BOINC couldn't stop all processes when Windows was suspending work but restarted all work units after Windows resume operation. I haven't had the problem in the recent weeks. It only occured as I rejoined BOINC a month ago when Einstein@home was the only project I was calculating for. Maybe a reason could be that Einstein@home could only use CPU at that time, my graphic driver was too old to use CUDA at first. So at that time there were two CPU work units running parallel.
BTW I'm running Windows Vista 32bit and my anti-virus program is GDATA.
RE: I stopped working of
)
That would be Activity - Suspend :-)
Suspended tasks are only removed from task manager if the computing preferences are set to
Though additionally started tasks should use another slot directory and thus the lockfile problem wouldn't occur.
To make sure that BOINC can't stop those processes you'd have to use
Advanced - Shut down connected client... [Extras - Herunterfahren des aktuell verbundenen Client... (falscher Genitiv ;-)]
But, as said before, you are probably right, as different "normally started" tasks shouldn't share a lockfile.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
Hi
)
Hi Gundolf,
Yes, my computing preferences were set this way.
Sorry, that I wasn't precise enough. To make it quite clear:
I had two active Einstein work units.
After resuming Windows operation there were four Einstein processes in the task list.
After supending activity in BOINC I found one Einstein process.
After killing it zero ;-)
Again starting activity in BOINC it had three processes in the task list (why three for two work units, no idea. What a pity I didn't write down the task names)
Gruß Ralph
RE: After supending
)
Okay, that shouldn't happen with your preferences set up as they are.
You'll have two processes for each S5R6 task and one process for each ABP1 task, so the count of three is easily explained.
The two processes for S5R6 are the "switcher" program (einstein_S5R6_3.01_windows_intelx86.exe), which selects the executable with the best-fitting optimisation for your processor, and the selected executable itself (einstein_S5R6_3.01_windows_intelx86_X.exe, with X being 0, 1 or 2 respectively).
The ABP1 executable (currently) is called einsteinbinary_ABP1_3.12_windows_intelx86.exe
If you intend to keep letting your computers go to sleep mode, you should consider setting the following preference accordingly:
[edit]...if they hibernate automatically. If you enter sleep mode manually, you'll have to suspend BOINC manually as well.[/edit]
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
RE: Now I searched the
)
Do you happen to recall the name of the process? In particular whether it was of the form "einsteinbinary_*", "einstein_*_windows_intelx86.exe", "einstein_*_windows_intelx86_2.exe" or "einstein_*_windows_intelx86_S5R6sse2.exe"?
BM
BM