if kill 9, $pid fails, is the error caught anywhere?

[it_says_BALLS_on_your forehead]

in '$!' or '$?' perhaps? I couldn't find it in the perldocs.

Thanks in advance for any assistance.

 

[it_says_BALLS_on_your forehead]

in '$!' or '$?' perhaps? I couldn't find it in the perldocs.

Thanks in advance for any assistance.

nvm, i gather it's in '$!'. On another note, does anyone know of any
reason besides 'No such process' that would lead to a return of 0 from
the kill function? trying to come up with actionable instructions for
support team.

 

[Paul Lalli]

does anyone know of any
reason besides 'No such process' that would lead to a return of 0 from
the kill function? trying to come up with actionable instructions for
support team.

Well the obvious answer is that the current user lacks permissions to
send a signal to a given process. Not just anyone can send a signal
to any given process.

Paul Lalli

 

[xhoster]

nvm, i gather it's in '$!'. On another note, does anyone know of any
reason besides 'No such process' that would lead to a return of 0 from
the kill function?

Sure. Trying to kill processes you don't own. (Unless you are root)

Xho

 

[it_says_BALLS_on_your forehead]

Sure. Trying to kill processes you don't own. (Unless you are root)

Ahh, didn't think about that. Thanks!

 

[it_says_BALLS_on_your forehead]

perldoc perlipc

'Signals' has some information.

When directed at a process whose UID is not identical to that of the
sending process, signal number zero may fail because you lack permission
to send the signal, even though the process is alive. You may be able to
determine the cause of failure using "%!".

did you really mean "%!"? or did you mean "$!"?

 

[xhoster]

did you really mean "%!"? or did you mean "$!"?

I think he really meant %!. Read the perldoc perlvar entry for it.

Xho

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
it_says_BALLS_on_your forehead

nvm, i gather it's in '$!'. On another note, does anyone know of any
reason besides 'No such process' that would lead to a return of 0 from
the kill function? trying to come up with actionable instructions for
support team.

What OS? On most OSes, there may be unkillable processes (not even by
root). [I rememeber getting ones on Solaris 2.6, when the floppy disk
started to misfunction....]

Hope this helps,
Ilya

 

[Michele Dondi]

did you really mean "%!"? or did you mean "$!"?

Since he also wrote

: unless (kill 0 => $pid or $!{EPERM}) {
^^^^^^^^^
^^^^^^^^^
: warn "$pid looks dead";
: }

it's clear enough that he meant C<%!>.


Michele

 

[it_says_BALLS_on_your forehead]

[A complimentary Cc of this posting was sent to
it_says_BALLS_on_your forehead

nvm, i gather it's in '$!'. On another note, does anyone know of any
reason besides 'No such process' that would lead to a return of 0 from
the kill function? trying to come up with actionable instructions for
support team.

What OS? On most OSes, there may be unkillable processes (not even by
root). [I rememeber getting ones on Solaris 2.6, when the floppy disk
started to misfunction....]

This is SunOS 5.8.

 

[it_says_BALLS_on_your forehead]

Since he also wrote

: unless (kill 0 => $pid or $!{EPERM}) {
^^^^^^^^^
^^^^^^^^^
: warn "$pid looks dead";
: }

it's clear enough that he meant C<%!>.

hehe, clear to you perhaps . i hadn't recognized that '%!' was a
hash named '!'--to me, it was just a magic variable--nor did i
interpret $!{EPERM} to be a hash lookup. of course now that you've
explained it i see it clearly. thanks!

 

[it_says_BALLS_on_your forehead]

cool, thanks. i've never come across that variable before. i just
incorrectly assumed A. Sinan fat-fingered it, since '%' is right next
to '$'.

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
it_says_BALLS_on_your forehead

What OS? On most OSes, there may be unkillable processes (not even by
root). [I rememeber getting ones on Solaris 2.6, when the floppy disk
started to misfunction....]

This is SunOS 5.8.

I think it should not matter. It is hard to imagine an OS
architecture which would not allow a device driver to define "Do not
interrupt programs which entered this chunk of my code" flag.

Anyone with more detailed knowledge?

Thanks,
Ilya

 

[Michele Dondi]

hehe, clear to you perhaps . i hadn't recognized that '%!' was a
hash named '!'--to me, it was just a magic variable--nor did i
interpret $!{EPERM} to be a hash lookup. of course now that you've
explained it i see it clearly. thanks!

Yes, sorry. I suggest you to get familiar with "this kinda things".
Whaterver "this kinda things" is: basically, special (as in
"predefined") variables are just like all other ones. They just have
some strange names, but the syntax associated to them is not special
nor stranger than that of regular variables.


Michele

 

[it_says_BALLS_on_your forehead]

It should have been obvious that I copied and pasted the paragraph from
the Perl documentation I referenced. You did read:

perldoc perlipc

Right?

Apologies, I have now. Another reason i thought you had mistyped was
that I tried a simple script where I attempted to kill a pid that I
knew did not exist and printed the error message captured in $!, so I
thought that was where the messages were stored. It didn't occur to me
that another variable would also provide insight as to the nature of
the error. Thanks for your help.

 

[anno4000]

[A complimentary Cc of this posting was sent to
it_says_BALLS_on_your forehead

What OS? On most OSes, there may be unkillable processes (not even by
root). [I rememeber getting ones on Solaris 2.6, when the floppy disk
started to misfunction....]

This is SunOS 5.8.

I think it should not matter. It is hard to imagine an OS
architecture which would not allow a device driver to define "Do not
interrupt programs which entered this chunk of my code" flag.

Anyone with more detailed knowledge?

No knowledge, just anecdotes.

No OS seems to be immune against stuck io calls, but there used to
be huge differences as to how often it happened. I remember one
particular version of HPUX (I don't remember which, it was about
10 years ago) that had to be rebooted regularly (2-3 times/week)
to get rid of unkillable processes blocking resources.

Other systems were much better in that respect, though none were immune.
I've always assumed that the better ones had a more useful timeout
mechanism.

Whatever the reason, these days I don't see large differences between
systems concerning stuck io calls. They're generally rare with
standard devices, but since the behavior depends at least in part
on the device driver, one might see more of them with exotic devices.

Anno