Hi List,
I just enabled USE_CGROUPS execd parameters and I observe that
- Relevant job cgroup is created in /dev/cpuset/sge
- Task PIDs can not be found in /dev/cpuset/sge//tasks
What could be wrong?
I also use ENABLE_ADDGRP_KILL=true and USE_QSUB_GID=false, son of GE version
Hi,
I've run into a problem recently where users jobs are stuck in the 'r' state.
It doesn't always happen, but it's happening enough to be a persistent error.
My guess is that it is IO realted (the jobs are accessing a NFS 4.1. share off
of a windows 2012 file server). I really don't know h
Hi,
Am 20.12.2016 um 22:20 schrieb Thomas Beaudry:
> Hi,
>
> I've run into a problem recently where users jobs are stuck in the 'r' state.
> It doesn't always happen, but it's happening enough to be a persistent
> error. My guess is that it is IO realted (the jobs are accessing a NFS 4.1.
>
Hi Reuti,
The jobs stay in the queue forever - and don't get processed. There are no
messages in the spool directory for these jobs.
Thomas
From: Reuti
Sent: Tuesday, December 20, 2016 4:25 PM
To: Thomas Beaudry
Cc: sge-discuss@liv.ac.uk
Subject: Re: [S
Am 20.12.2016 um 22:37 schrieb Thomas Beaudry:
> Hi Reuti,
>
> The jobs stay in the queue forever - and don't get processed. There are no
> messages in the spool directory for these jobs.
The "r" state is already after the "t" state. With NFS problems they are often
stuck in "t" state. What
Hi Reuti,
It is: loglevel log_warning
In case it helps, here is the full output:
#global:
execd_spool_dir /opt/sge/default/spool
mailer /bin/mail
xterm/usr/bin/xterm
load_sensor none
prolog
