1

I'm on a multi user login-node, a front end node to a large national bioinformatics compute farm, running Linux. Many users misbehave by running computationally intensive jobs on the login-nodes. I don't. I'd like to be nice. In fact, I even would want my login shell to run at nice level 4 instead of the default 0 (zero).

What's the most convenient and non-contrived way of reniceing ones login shell?

My current setup:

I'm running ast-ksh (KornShell 93) within one or several tmux sessions. The default shell on the system in bash, but I exec -l ksh93 from ~/.bash_profile and then I reattach to any running tmux session from my ~/.profile, or create a new one if none exist.

Snippet from ~/.bash_profile: I don't want to touch bash even with a stick, so all I'm willing to do with it is to have an exec of my preferred shell. It's not easy to change one's default shell on this system...

if [ -f $HOME/sw/bin/ksh93 ]; then
    exec -l $HOME/sw/bin/ksh93
fi

Snippet from ~/.profile: I'm detecting whether I'm already in a tmux session, and if I'm not, and I'm logged in over SSH, I attach to or spawn one.

if [[ -z $TMUX ]]; then
    ssh-add

    if [[ -n $SSH_TTY ]]; then
        if tmux has-session 2>/dev/null; then
            exec tmux attach-session
        else
            exec tmux
        fi
    fi
fi

Snippet from ~/.tmux.conf:

set -g default-shell "$HOME/sw/bin/ksh93"

Where in this would I renice ksh93, and how?

Kusalananda
  • 320,670
  • 36
  • 633
  • 936
  • Which one do you want to renice? Your login shell (bash)? Or the shell you launch afterwards (ksh93)? – terdon Jun 13 '15 at 11:54
  • I don't think it really matters. If I managed to renice the bash login shell, the nice level would be carried over to tmux and ksh93, right? – Kusalananda Jun 13 '15 at 12:06
  • Isn't adding `renice 4 $$` to your ~/.profile` enough then? – terdon Jun 13 '15 at 12:17
  • That does not *add* to the niceness value, does it? Then maybe that's all I need... Will test next time I'm at the screen. Write it up as an answer and I'll accept it. Funny, I thought it would be trickier. – Kusalananda Jun 13 '15 at 12:22
  • The [GCC Compile Farm](https://gcc.gnu.org/wiki/CompileFarm) has similar issues on occasion. Usually someone is using all of the compute cycles. The Compile Farm admins kill the job and point people to the policy of only using half the logical CPUs or risk being killed. It seems to work fine, and I don't recall seeing user access revoked. –  Aug 08 '16 at 03:26

1 Answers1

6

It should be enough to modify your ~/.bash_profile so it reads:

if [ -f /bin/ksh93 ]
then
    renice -n 4 $$
    exec -l /bin/ksh93
fi

The renice -n 4 $$ will set the nice value of the current shell ($$) to four, causing subsequent commands launched by that shell to inherit the same niceness value.

I have not tested in a tmux session, but it works as expected when logging in without it:

$ su - testuser  ## whose ~/.bash_profile contains the lines above
$ ps -eo "%p %y %x %c %n" | grep ksh
16894 pts/9    00:00:00 ksh93             4 #<-- the nice value
terdon
  • 234,489
  • 66
  • 447
  • 667
  • This solves my "problem". Many thanks! – Kusalananda Jun 13 '15 at 16:51
  • @Kusalananda huh, that was simple :) I doubt you really want to do this though. This means that _all_ your subsequent processes will have a low priority and you [won't be able to](http://unix.stackexchange.com/q/119303/22222) change it back to normal. I would leave the login shell alone and just run intensive jobs using `nice`. There's little benefit to running `echo foo` with a nice value of 4 for example. – terdon Jun 13 '15 at 16:56
  • No, anything computationally intensive is submitted through SLURM or LSF (or OpenLava), never directly from the command line. This is *exactly* what I wanted. Jobs submitted through the job queues won't inherit the niceness value (and would be executed on hosts where the resource requirements are met and with exclusive use of the allocated CPUs). The odd Vim session or gzipping *should* be run with higher nice value *to be nice to others* who are using the login nodes :-) – Kusalananda Jun 13 '15 at 17:03