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:
    begin-time end-time single-user(s)
  1. 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:
    1. 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
  2. RE-OCCURING SINGLE-USER TIMES

  3. 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
  4. 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.)
  5. 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.
  6. NOTIFY USERS IF THIS IS NOT A NORMAL SINGLE-USER TIME

  7. 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.)
  8. 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.
  9. 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.
  10. 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.
  11. 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:
  1. sut runs submitSUTimes.sh:
    this shell script executes an awk script (spawnSUTs.awk) to create tmp/temp.sh
  2. 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.
  3. The "at" jobs submitted for each single-user time are:
    1. a stdin job that sets tmp/SUT_users and tmp/MUT_users, and which creates a login restriction message (tmp/nologin).
    2. startSUT.sh -- stops all jobs owned by users in tmp/MUT_users and restricts logins.
    3. realTime.sh -- converts all jobs owned by users in tmp/SUT_users to real-time with high-priority.
    4. startMUT.sh -- continues all jobs stopped by startSUT.sh and removes the login restriction.
    5. timeShared.sh -- converst all jobs owned by users in tmp/SUT_users to time-shared.
    6. a stdin job that removes the tmp/nologin file, making the scripts believe that it is now multi-user time.