RE: Why KILL rather than XCPU on timeout in GNU/Linux?

[Marshall, Simon]

Spot on.  Yes, if I use ulimit -St to set the limit I get a SIGXCPU
instead.  Many thanks, Simon.

-----Original Message-----
From: Dave Rutherford [mailto:dave@tmbg.org]
Sent: 21 August 2003 13:03
To: Marshall, Simon
Subject: RE: Why KILL rather than XCPU on timeout in GNU/Linux?


You're right; Linux does have SIGXCPU.  I didn't see it listed
in the signal man page or in signal.h, so I jumped the gun there.
Now you've got me wondering why it isn't used in this case.

Have a look at kernel/timer.c, do_process_times.  It looks like
SIGXCPU is sent but later (which could be immediately) followed
up by SIGKILL once the hard limit is reached.  Maybe you're setting
both limits the same under Linux, and the lower-numbered signal
gets delivered first?

Dave

On Thu, 21 Aug 2003, Marshall, Simon wrote:

> Hi Dave, it does in the sense that it defines SIGXCPU to be the usual
> value rather than equal to SIGKILL.  But I guess it's not a bash issue
> anyways.
>
> -----Original Message-----
> From: Dave Rutherford [mailto:dave@tmbg.org]
> Sent: 20 August 2003 18:01
> To: Marshall, Simon
> Subject: Re: Why KILL rather than XCPU on timeout in GNU/Linux?
>
>
> On Wed, 20 Aug 2003, Marshall, Simon wrote:
>
> > Hi, this isn't so much a bug report as a question.  It might not
even
> > have anything to do with bash.
> >
> > With bash on Solaris, if I specify a CPU limit with ulimit -t, then
a
> > process gets a SIGXCPU on timeout.  With bash on GNU/Linux (SuSE
> > 2.4.20-4GB), a process gets a SIGKILL.  Why is this?
>
> Probably because Linux doesn't have a SIGXCPU.  It's the kernel that
> determines what to do when a limit is reached.
>
> Dave
>