Very Computer

high all

i'm using tcsh under 5.4. my man pages say that i can
limit the resources of a process - but i cannot. i was
able to limit filesize, that was no problem. but i
was not able to limit cputime as my man pages suggest.

i tried:   limit -h cputime 0:20
and this limit was actually set, but when a child
process of this shell needs more than 20 seconds
NOTHING happens, the process continues without aborting
or any reaction. if i were a shell :-) i'd send
a SIGKILL to the process when it has reached its limits.

why does this not happen?????? please answer, because
we have a buggy program here that kills our main server
several times a day...

    c u
        tobias
---
---------------------------------------------------------------------------
Tobias Ruland (student at Dept. of Artificial Intelligence, Univ. Erlangen)

      (Please write in ENGLISH, GERMAN or FINNISH)
WWW:  http://www8.informatik.uni-erlangen.de/~tsruland

This will cause a kill -XCPU to be sent to any process exceeding
20 seconds.

: i'm using tcsh under 5.4. my man pages say that i can
: limit the resources of a process - but i cannot. i was
: able to limit filesize, that was no problem. but i
: was not able to limit cputime as my man pages suggest.

: i tried:   limit -h cputime 0:20
--

  ,;( )__, )~\|  |
 ;; //   '--;    | Gin-N-Tonic   endurance horse
 '  ;\    |      | Luv on Fire   trusty trail horse

SIGXCPU is by default ignored on Solaris 2.x, I don't know why :-(
This breaks limit cputime <val>

Joerg

--
Private:J?rg Schilling Seestr. 110 D-13353 Berlin      (030)452 55 85


If you don't have iso-8859-1 chars my name is           J"org Schilling

        symixsrv% uname -a
        SunOS symixsrv 5.4 generic sun4m sparc
        symixsrv% cat foo.c
        main()
        {
                for (;;)
                        ;
        }
        symixsrv% gcc foo.c
        symixsrv% limit cputime 0:05
        symixsrv% ./a.out
        Cpu Limit Exceeded (core dumped)

.... Of course, if your login shell is /usr/bin/csh, csh hides this bug!

The bug is located in init(1M) and can be found - if not fixed - on all SYSVr4
implementations.

I would call this a serious bug, as it breaks the behavior that is guaranteed
by the manual (signal(5)). The correct behaviour of the kernel is superseeded
by init(1M).

Here is the buggy part in init.c:
                /*
                 * Reset all signals to the system defaults,
                 * making sure that SIGXCPU and SIGXFSZ remain
                 * ignored, for backward compatibility.
                 */
                for (i = SIGHUP; i <= SIGPWR; i++)
                        oldsigs[i] = sigset(i, SIG_DFL);

        (SIGXCPU has been ignored before this)

I believe the author of the comment above didn't realize the effect of his
act of - wrong understood - good will.

To verify:

log in on an account with the default shell (i.e. root)
% cat foo.c
#include <signal.h>
#include <sys/syscall.h>

main()
{
        printf("value of SIG_IGN: %d, current value of XCPU: %d\n", SIG_IGN,
                        syscall(SYS_signal, SIGXCPU, SIG_DFL));

Quote:}

Joerg

--
Private:J?rg Schilling Seestr. 110 D-13353 Berlin      (030)452 55 85


If you don't have iso-8859-1 chars my name is           J"org Schilling