On 2014-03-27 17:07, Philip Guenther wrote:
> On Thu, Mar 27, 2014
at 3:00 PM, Philip Guenther <guent...@gmail.com> wrote:
>
>> On Thu,
Mar 27, 2014 at 2:28 PM, sven falempin <sven.falem...@gmail.com [1]>
wrote:
>>
>>> Sometimes i feel curse (or maybe just tired) :
main::(/bin/check_network.pl:164): my $src = system('/usr/bin/pkill -HUP
-f "dhclient: trunk0"'); DBn main::(/bin/check_network.pl:165): if
($src) { DBp $src 33024 Of course pkill is supposed to return 0,1,2 or 3
and it does in the shell
>> perldoc -f system ... The return value is
the exit status of the program as returned by the "wait" call. To get
the actual exit value, shift right by eight (see below). See also
"exec". This is not what you 33024 >> 8 == 129
>
> (Stupid gmail
control-enter==Send)
>
> So, why is it returning 129? Well, since you
gave system() a single
> string it's actually invoked via the shell. Why
would the shell
> report a status of 129?
> ? The exit status of the
last non-asynchronous command executed.
> If the last command was killed
by a signal, $? is set to 128
> plus the signal number.
>
> So, pkill
is dying with signal 1 == HUP. Hey, wait a minute, pkill's
> criteria
matches its own command line, so it will kill itself! Time
> to be more
clever about the criteria...
Which goes back quite neatly to my comment
about correct pkill usage not necessarily being self-evident.
I
thought pgrep/pkill specifically excluded themselves?
Oh - it's
killing the subshell that invokes pkill, isn't it? Which propagates the
signal through the process group, which includes pkill... argh!
Yup,
confirmed:
# sh -c "pgrep -lf pgrep"
31775 sh -c pgrep -lf pgrep
but...
# sh -c "pgrep -lfx pgrep"
#
Perhaps more useful than the
-x option in this case is the fact that pgrep/pkill take REs as
patterns, so just use "^":
my $src = system('/usr/bin/pkill -HUP -f
"^dhclient: trunk0"');
-Adam
Links:
------
[1]
mailto:sven.falem...@gmail.com
