[GRLUG] problem with pkill/killall

[Eric Beversluis]

On Thu, 2013-09-05 at 03:58 +0000, Nathan Phillip Brink wrote:
> On Wed, Sep 04, 2013 at 10:08:09PM -0400, Eric Beversluis wrote:
> >      A. On Wed, 2013-09-04 at 20:15 -0400, Greg Folkert wrote:
> > > On Wed, 2013-09-04 at 19:12 -0400, Eric Beversluis wrote:
> > > > My system has a problem in that its spawning multiple versions of a
> > > > command and never ending the earlier versions. Why it's doing so is the
> > > > next problem. But first I have to figure out how to kill them.
> > > > 
> > > > As nearly as I can tell from the web and the man pages, I should be able
> > > > to do that with 'pkill' or with 'killall', using part of the name.
> > > > 
> > > > The processes are:
> > > > 
> > > > root     27514 27508  0 18:20 ?        00:00:00 /bin/bash -c php
> > > > -f /var/www/virtual/vtiger.cyberacc.com/modules/CalendarSync/syncCalendarFromGA.php > /home/mundane/etc_cron_rept2.txt 2>&1
> > > > root     27517 27507  0 18:20 ?        00:00:00 /bin/bash -c php
> > > > -f /var/www/virtual/vtiger.cyberacc.com/modules/CalendarSync/syncCalendarFromVT.php > /home/mundane/etc_cron_rept2.txt 2>&1
> > > > 
> > > > So it seems I should be able to do:
> > > > 
> > > > pkill  syncCalendarFrom
> > > > 
> > > > or killall syncCalendarFrom
> > > > 
> > > > and thus get rid of all of them. But neither seems to work.
> > > > 
> > > > Some of my efforts:
> > > > [root at server ~]# pkill syncCalendarFrom
> > > > [root at server ~]# pkill "-c php
> > > > -f /var/www/virtual/vtiger.server.com/modules/CalendarSync/syncCalendarFromGA.php > /home/mundane/etc_cron_rept2.txt 2>&1"
> > > > pkill: invalid option -- 'c'
> > > > Usage: pkill [-SIGNAL] [-fvx] [-n|-o] [-P PPIDLIST] [-g PGRPLIST] [-s
> > > > SIDLIST]
> > > > 	[-u EUIDLIST] [-U UIDLIST] [-G GIDLIST] [-t TERMLIST] [PATTERN]
> > > > [root at server ~]# pkill "php
> > > > -f /var/www/virtual/vtiger.server.com/modules/CalendarSync/syncCalendarFromGA.php > /home/mundane/etc_cron_rept2.txt 2>&1"
> > > > 
> > > > ??
> > > > 
> > > > Thanks.
> > > 
> > > Do you know the Parent Process ID? If so you can kill that and the
> > > pattern. Also try this if no dice:
> > > 
> > > # pkill -9 -f syncCalendarFromGA.php ; \
> > > pkill -9 -f syncCalendarFromGA.php ; \
> > > pkill -9 -f syncCalendarFromGA.php ; \
> > > pkill -9 -f syncCalendarFromGA.php ; \
> > > pkill -9 -f syncCalendarFromGA.php ; \
> > > pkill -9 -f syncCalendarFromGA.php
> > > 
> > > If that doesn't do it... then add "-P $PPID" before the "-f" where you
> > > know the Parent ID in place of $PPID.
> > > 
> > > You also have to use "-f" with pkill to get it to match anything other
> > > than "php" 
> > > 
> > > From the man page:
> > > 
> > > 	-f, --full
> > > 		The pattern is normally only matched against the process
> > > 		name.  When -f is set, the full command line is used.
> > > 
> > > That is why I included it.
> > > 
> > ========
> > Thanks, Greg. 
> > --There seem to be many different parent processes, so that approach
> > won't work here.
> > --I didn't grasp the meaning of the -f option because I was thinking
> > that the whole thing was the command--that's why I tried to put it in
> > quotes. I gather, thinking about what you wrote, that only 'php' is the
> > command.
> 
> From the ps output you posted, if those are the particular procs you
> wanted to kill, only “bash” is part of the command name itself. Which
> might lead you to run “pkill bash” which would knock out the very
> shell you typed that into and, likely enough, even your X session.
> 
> Now, I do wonder, are the procs in the ps output you showed actually
> the procs where the problem is happening? If this is so, then bash is
> somehow hung up weird. But I don’t immediately notice anything in
> those commands that would cause bash itself to hang up, so I am going
> to guess that different processes are actually hung up. I.e., I am
> going to guess that bash is doing fine and just waiting for other php
> procs to exit. Ideally, you would kill the process that is actually
> hung (php, not bash?) so that the others waiting on it can more
> gracefully exit (see the signal info below).
> 

The commands were generated by cron and have now been disabled: they ran
every 10 minutes to sync vtiger calendar with Google calendar. I think
the calendar in vtiger is somehow screwed up--it's showing 317000
events--probably a problem with calendar import, as many seem the same
event entered over and over. My hypothesis is that the php sync
processes weren't closing because they were never finishing with those
31700 events. So I have to clean those out before trying the sync
process again. Hopefully we can clear that up with help from vtiger and
from Boru corp.

Regarding pkill: I ended up rebooting the server after disabling the
cron commands. But now I understand better how I can use pkill in the
future.

Thanks to all.

> > --also, the examples I saw didn't use the -9.
> 
> -9 is equivalent to -KILL which means to send SIGKILL. If you don’t
> specify -9 or -KILL to killall or pkill, the default is -TERM which
> sends SIGTERM. Processes can catch and “handle” (and, thus, ignore)
> SIGTERM. You should try using SIGTERM first because sometimes
> processes’ SIGTERM handlers can do just a bit of cleanup and exit
> somewhat gracefully. For processes that are truly locked up, you may
> need to use SIGKILL which cannot be intercepted.
> 
> > 
> > Thanks again.
> > 
> 
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug