I am currently trying to implement a “conditional unlock” based on CPU load.
This is the current relevance I am using:
(locked of action lock state) AND (hour_of_day of time (local time zone) of now < 5) AND
(preceding text of first "," of (current date as string) = "Sun") AND
(following text of first "=" of (property "Loadpercentage" of select object "Loadpercentage from Win32_Processor where
DeviceID='CPU0'" of wmi as string) as integer<5)
In case of success, it should execute this:
action unlock "{now}"
But it does not work, the result is “This computer is locked.”. Why is the unlock clause not working, it is the same as it is executed if I manually unlock a system (which I want to automate for a group of systems).
This won’t really work and is generally not a good idea… Here are some notes:
The action is re-evaluated periodically, but it will only be at a point in time (maybe once every few minutes)… I would fully expect the CPU load to vary fairly randomly at these times and it seems like a bad idea to tie the locking behavior the temporary CPU %.
I think this wmi query is fairly expensive and I am pretty sure it will spike the CPU just by running this query.
We have several laboratory systems which have a very high cpu load during their (uninterruptable) analysis phase. Because of this, the systems gets locked by the lab administrators.
Now we had the idea to do an automated unlock in a specified time range, which has been defined to be sunday morning before 5 o’clock. The only automatically detectable way is to look at the cpu utilization. It is not possible to have a look at the running processes (because the processes are always running even if the system has nothing to do).
My relevance is built in that way, that it only gets into the high cost part with the wmi query in this time range and if the system is currently locked. And yes, I can see a short peak in the performance monitor, but that is ok. It is also possible to create a specific site for this fixlet and to assign only these systems to that site that the fixlet is not analysed by all other locked systems (not tested yet).
But my question is something different:
In my test environment, I simulated the complete process and the fixlet was relevant somewhere in the night (controlled by another action, which stopped a very time consuming process). But the system did not get unlocked, it reported “locked”. And the question is, why it did not get unlocked, why did it reported “locked” instead of executing the unlock action?
I agree with Ben that your solution is likely to only cause problems.
Since your requirements state that you are allowed to unlock Sunday before 5, why not just use that as your locking criteria with a dynamic locking policy:
__Lockstate = {not (current day_of_week = Sunday AND hour_of_day of current time_of_day < 5)}
Also, it’s possible that the client may not have unlocked if the CPU was under high load. The client trys to be good about taking actions only using “extra” CPU cycles.
yes, seems to work for “one shot” (only one time). Test is currently still running and I am waiting for a more detailed report.
I am using the Seti@Home Client installed as a service to generate the needed CPU utilisation
I respect your concerns about the usage of the wmi query to check the cpu utilisation, but cannot see any other alternatives so far. It is not a problem is a possible unlock is missed onetime, but it would be really very helpful to get an automatism on this. I can see a very short peak of about 30% cpu usage on one processor, which is acceptable for me.
To make the usage more easy for our lab administrators, I will now try to create a fixlet of these results and the generated code from the Console (create by adding this dynamic setting in my test). I will also test if I can setup an action based on this fixlet with a “retry if relevant again”.
it is working with the EDIT context menu, but not working as a fixlet action. It always tells me that the client is locked. I cannot see a difference in the created action between my fixlet and the action created from the console while using the EDIT context menu.
If have added the fixlet as an attachement (note: is currently coded to get relevant on wednesdays during working hours to have it more easily during tests - only running currently in our small test environment).
To make sure it reapplies ensure that the ‘Ends On’ option is unchecked.
You should be able to get it to reapply and it should be very reliable.
As for your WMI method, our objections are that a) WMI queries are expensive b) the WMI query is likely to be inaccurate and c) the only way to get the computer to unlock would be to put this as a settings action and those are evaluated with higher priority, thus exacerbating the problems associated with a) and b).
