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

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

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

Snippet from ~/.tmux.conf:

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

Where in this would I renice ksh93, and how?

  • 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 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.
    – user56041
    Aug 8 '16 at 3:26

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

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

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
  • 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 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

This site is temporarily in read only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .