[comp.unix.ultrix] Nice bug

glenn@bryant.NCD.COM (Glenn Shapland) (04/02/91)

I have an X application which starts up like a daemon
using the following code.

    /* prevent reacquisition of a controlling terminal */
    if (fork() != 0) exit(0);
    /* change process group */
    if (setpgrp(0,getpid())== -1)
      PrintLogCon(msglog,"setpgrp failed [%s]\n",SYSERR);
    /* make sure we don't have a control terminal */
    if ((ftty=open("/dev/tty",O_RDWR)) >= 0)
    {
      /* lose terminal */
      ioctl(ftty,TIOCNOTTY,0);
      close(ftty);
    }
    /* close all open files */
    for (ftty=0;ftty<_NFILE;++ftty) close(ftty);

The problem is that when it first starts up it runs fine and
looks like this with ps:

mfg      10486  0.0  2.5 1812  488 ?  S     0:00 station3b -display 138.43.2.6:

but after some period of time (usually 24 hours) the load average
of the system goes up and the application gets niced. If I try to
manually un-nice the application the nice runs without complaining
but has no effect.

mfg      10486  7.8  1.3 2264  252 ?  R N 875:54 station3b -display 138.43.2.6:

The application does use a port on a DecServer 200. As in most X applications
this process should be sitting in a select system call waiting for something
to do. 
 
Has anyone seen similar symtoms or have any ideas that I could try?

-glenn

farrell@pangea.Stanford.EDU (Phil Farrell) (04/12/91)

In article <4780@lupine.NCD.COM> glenn@bryant.NCD.COM (Glenn Shapland) 
complains that a long-running application of his will be "niced" by the 
kernel to a lower priority after a while, and he is unable to renice it
back to the original priority.  

I don't know if this is related, but DEC Ultrix Support in Atlanta just
sent me a patched version of the kernel routine kern_synch.o for 
RISC Ultrix 4.1 (in an attempt to cure an unrelated problem) with this
note on the problem it is supposed to fix:

	"Fix for process priority calculations on Mips machines.  The
	proc structure field "p_slptime" was not getting clear after
	a setrun.  This will prevent the priority for this task to get
	recalculated."

Perhaps Glenn should contact Ultrix Support to see if this is related 
to his problem.

-Phil Farrell, Computer Systems Manager
Stanford University School of Earth Sciences
farrell@pangea.stanford.edu