How can I get single-user access to ParaMount SUN machines?
We currently have single-user times set up on peta.ecn, lagavulin.ecn,
bernina.ecn, and longmorn.ecn.
Anyone with group paramnt can set up a single-user time as described below.
Single-user time is set up to allow your shell or script to have access
to the machine while all other users are restricted from logging in and
all currently running jobs are suspended.
However, some jobs on the ECN supported SUN's cannot be stopped or delayed.
See the FAQ for more on what may be influencing your timings on our SUN's.
SINGLE-USER TIMES
Please follow the guidelines below carefully when entering a single-user
time in the /home/peak/a/sut/single-user-times/SUTimes/MACHINE
file. (MACHINE is "peta", "lagavulin", ....) (The scripts affect all users of the machine.)
FORMAT OF THIS FILE
This is a comma-deliminated file with three fields:
-
VALID TIMES:
begin-time can be any time at least 3 minutes
after the end time of a previous end time (on the same day.) end-time
needs to be at least 3 minutes after the begin time.
The single-user scripts are currently being run every odd hour (1am, 3am,
..., 23), so begin-time must be later than the next time the script
is run.
The times are used by "at" (see spawnSUTs.awk) and can take any
explicit time format that "at" accepts, such as: 3:25pm or 15:25
.You also can specify a date, if it is later than the next time the single-user
setup script gets run. This date can be a day of the week or the explicit
month and day. For example:
3:25am thu --> means 3:25am on the next Thursday morning.
3:25am mar 5 --> means 3:25am on March 5th.
NOTE THAT "thu" (NOT "thr") IS Thursday.
single-user(s) This field is optional. The single-user
can be one or more logins (separated by spaces.) The designated single-users
will not have their jobs stopped during this single-user time.
If you do not specify a single-user (i.e., if only a begin and end time
are specified,) then there will be no conversion of processes from time-shared
to real-time mode . Also, all jobs (including any
of yours that are running at begin-time,) will be stopped at the begin
time.
If an asterix ("*") is the first character in this field then the "sut"
account will mail everyone on the mailing list about your single-user time.
(See below about notifying other users.)
eg.,
4:00am , 8:00am, barmstro
8:05am , 8:00pm, *barmstro
9:00pm tue, 9:45pm tue, aslot barmstro seon
-
RE-OCCURING SINGLE-USER TIMES
These take place every day (they never get commented out of the SUTimes
file.) They are indicated by an "*" in front of the begin time. (Don't
overlap your requested times with these.)
eg.,
* 3:00am , 7:00am, mjvoss
-
SINGLE-USER TIME USING THE SINGLE-USER QUEUE
If there is no specific end-time to the single-user time slot then
prefix the second field with an "*", such as: 5:55pm friday,* noon saturday
This will cause the single-user time slot to end when no more jobs are
present in the s-queue, with a hard-limit of noon.
Single-users could submit jobs to the single-user queue to run any time
before the single-user time ends. These jobs will get executed between
5:55pm Friday and noon on Saturday in the order of their submit time. By
noon on Saturday, or earlier if the single-user queue is drained quicker,
multi-user time will begin. (This method of single-user time has not been
tested with all the newer features yet.)
-
VALID SINGLE-USER TIMES CANNOT OVERLAP
Just make sure that your new time does not overlap with any of the
others.
You can use "sudo atq" to check which jobs are queued by sut. There should
be two or three jobs in the "at" queue for the begin time and two or three
for the end time. (You can also see anyone else's jobs waiting to be executed
in this list.)
Previously submitted single-user times are commented out with "#SUBMITTED"
in this file. Previous requests are also logged in SUTimes.log
.
Also, you should begin your single-user time a little bit after a previous
one ends. Exactly at the end time, the sudoStartMUT (which continues
multi-user time) is executed and it may take a couple of minutes to execute
these scripts. So, give a little buffer (like 5 minutes) between single-user
times.
-
NOTIFY USERS IF THIS IS NOT A NORMAL SINGLE-USER
TIME
In /home/peak/a/sut is a file: .mailrc which
contains a mail alias with all current users of the system. You can use
this alias (just add it to the .mailrc in your home directory
and then send mail to multi_peta, multi_lagavulin,
etc., depending on which machine you are on) to notify everyone on the mailing list.
Alternatively, if the first character of the 'single-users' field is an
asterix ("*"), the sut account will automatically mail a notification to
all on the list.
eg.,
3:00pm,9:00pm,*mjvoss barmstro
(This will set up a single-user time for 3 - 9 pm and mail the users
on the list that Mike and Brian are using the machine.)
-
ALLOCATE SINGLE-USER TIMES IN ADVANCE
We need to kindly notify all users in advance, preferrably a day in
advance if you want time outside of the normal time allocated to single-users
(which is 3:25am till 8:25am every weekday morning.)
For extra time on the weekends, it is good to notify everyone before the
end of the workday on Friday.
-
NORMAL SINGLE-USER TIME
Every day 3:25am till 8:30am is single-user time. You can take any
amount of this time without notifying all users of the machine. Other times you will need to notify all users in advance.
-
INTERACTIVE SINGLE-USER TIME
You can allocate an interactive single-user time for yourself by including
your login in the list of single-users and starting an xterm on the
machine some time before your single-user time begins. When logins are
restricted then your xterm will remain active.
-
REALTIME
The SUN systems managed by ECN are set up for time-shared multi-user
use. So, jobs with a higher priority do not necessarily execute before
jobs with a lower priority. The scripts for single-user time make sure
that your processes are set to real-time and are given a high priority.
Then, your jobs will gain access to resources and execute before
almost any other process.
Switching your processes to real-time only occurs if you include
your login in the list of single-users and your jobs are running (or
the script that executes your jobs is running) at the time of begin-time.
DETAILS:
Here are the actions that take place for each line in this file:
-
sut runs submitSUTimes.sh:
this shell script executes an awk script (spawnSUTs.awk)
to create tmp/temp.sh
-
sut then immediately runs tmp/temp.sh:
which uses "at" to submit jobs and then comments out all single-user
times just submitted in this file.
-
The "at" jobs submitted for each single-user time are:
-
a stdin job that sets tmp/SUT_users and tmp/MUT_users,
and which creates a login restriction message (tmp/nologin).
-
startSUT.sh -- stops all jobs owned by users in tmp/MUT_users
and restricts logins.
-
realTime.sh -- converts all jobs owned by users in tmp/SUT_users
to real-time with high-priority.
-
startMUT.sh -- continues all jobs stopped by startSUT.sh
and removes the login restriction.
-
timeShared.sh -- converst all jobs owned by users in tmp/SUT_users
to time-shared.
-
a stdin job that removes the tmp/nologin file, making
the scripts believe that it is now multi-user time.