El 17/06/14 17:23, Reuti escribió:
Am 17.06.2014 um 15:46 schrieb Txema Heredia:
Basically, the JSV checks the CLIENT parameter. If it is equal to "qlogin",
then checks if there is any h_rt, and sets a limit on 2h:10min if there is none, while
showing a colorful warning message to the user so they know that there is a time limit.
Then, it also sets all.q as a hard queue if there is none (or *) and also sets
the core binding policy.
This works wonders when I run it as a client jsv by using "qlogin -jsv
/opt/gridengine/default/common/jsv.pl". The message appears, the limit is set, and
the job runs fine.
But, once I set this as a server JSV (by qconf -mconf global), the time limit
no longer applies.
As far as I've been able to find the following behaviours differ from running
it as client or server jsv:
- The 'CLIENT' parameter changed, from 'qlogin' to 'qmaster'. This skips all my
"if" in the jsv and stops checking for time limits. Can I trust this? Why is
this 'qmaster' appearing? Now both qsub's and qlogin's show the same command. How can I
distinguish them?
I found the same:
http://gridengine.org/pipermail/users/2012-September/004808.html
You can check for QRSH_PORT port according to William's post.
Thank you as usual, Reuti.
That QRSH_PORT env variable allows to differentiate between qlogin and
qsub commands. But I am still having some problems.
- The jsv_show_params() command shows nothing. Neither on stdout nor in
/opt/gridengine/default/spool/qmaster/messages This makes debugging really
cumbersome
For me it's working, being it Bash or Perl.
06/17/2014 17:13:30|worker|pc15370|I|got param: A='sge'
06/17/2014 17:13:30|worker|pc15370|I|got param: GROUP='users'
06/17/2014 17:13:30|worker|pc15370|I|got param: N='test.sh'
06/17/2014 17:13:30|worker|pc15370|I|got param: CMDNAME='test.sh'
06/17/2014 17:13:30|worker|pc15370|I|got param: CMDARGS='0'
06/17/2014 17:13:30|worker|pc15370|I|got param: JOB_ID='11553'
06/17/2014 17:13:30|worker|pc15370|I|got param: M='reuti@pc15370'
06/17/2014 17:13:30|worker|pc15370|I|got param: CLIENT='qmaster'
06/17/2014 17:13:30|worker|pc15370|I|got param: VERSION='1.0'
06/17/2014 17:13:30|worker|pc15370|I|got param: USER='reuti'
06/17/2014 17:13:30|worker|pc15370|I|got param: CONTEXT='server'
My bad. I had my loglevel set to log_warning instead of log_info. Now I
can see these messages.
- No message can be sent to the user. Being it info, warning or error. The
user won't know if I have set a time limit to his session
Yep, only for "jsv_reject_wait" a message can be displayed. Despite the fact that also for
"jsv_correct" and "jsv_accept" a message can be specified too.
-- Reuti
Trying to overcome this, I thought of making my JSV add an environment
variable "IS_QLOGIN=true" whenever it detects the QRSH_PORT. Then, a
prolog script in the execution host would check that environment
variable and print, if needed, the timelimit message to the user.
BUT, the prolog script cannot print anything to the standard output.
(¿because it is run before the actual session begins?)
So, I thought about modifying the .bashrc file (or any other of the
several scripts under /etc/profile.d/), and make it read that
"IS_QLOGIN=true" environment variable. But, again, the fates are against
me, and qlogin commands cannot use the "-v" parameter. Even if I use the
jsv_add_env() command in the JSV script, that environment variable is
passed to the prolog script, but is nowhere to be found once the "real"
qlogin session starts.
I could also ignore both the JSV and the prolog scripts, go directly to
the .bashrc script and check there for the presence of (or lack thereof)
variables like JOB_ID or JOB_NAME. That would allow me to distinguish
between qlogin and qsub sessions (qlogins and ssh environments are
identical). But then, again, I won't have access to anything able to
tell the script if there is a timelimit set.
The only solution to all this mess that comes to my mind would be to
make /etc/motd writable by all users, have the prolog script to modify
it with the timelimit message, and then have some sort of contraption in
/etc/profile.d/ that resets the motd back to its previous non-qlogin
version.
Does anyone have a better (or less-prone-to-failure) idea?
Txema
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
