Re: [HTCondor-users] Desktop Policy renders workstations unusable

[Daniel BrÃckner <daniel.brueckner@xxxxxxxxxxxxxxxxxx>]

Hi Alexander,

I ran into the same issue last month after upgrading to condor 23.0.

https://www-auth.cs.wisc.edu/lists/htcondor-users/2023-December/msg00023.shtml 


The KBDD isn't resetting KeyBoardIdle. Workstation nodes won't change to 
owner state if a user returns.

I created a workaround using a (cron triggered) script which detects 
user activity and forces a "condor_drain". But I would prefer the 
condor solution as before.

Best,

Daniel

Am 26.01.2024 um 12:40 schrieb Alexander Neuwirth:
> Dear HTCondor-Team/Users,
>
> We use HTCondor at our institute but keep running into conflicts 
> between machine owners and HTC users. It is a recurring problem that 
> workstations become unusably slow due to different kinds of resource 
> exhaustion (CPU, IO, memory, ...), when working on HTC jobs. We are 
> using the default DESKTOP policy, but jobs are apparently not 
> preempted by keyboard use or other user actions. Ideally, we'd like it 
> to preempt jobs on any indication of non-HTC activity on the machine, 
> preferably including SSH connections. Are there recommendations for 
> such a configuration?
>
> One ugly workaround our users use to "free" their PCs from Condor is 
> commands akin to `watch -n1 condor_vacate`, but this should not be 
> necessary with the default desktop policy in my opinion. Is this a 
> known problem or just some configuration error on our side? You can 
> find our config files attached.
>
> Best,
> Alexander
>
>
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
>
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/htcondor-users/