On Tue, Mar 25, 2014 at 3:44 PM, Adam Thompson <athom...@athompso.net> wrote: > On Tue 25 Mar 2014 02:08:17 PM CDT, Josh Grosse wrote: >> >> On 2014-03-25 14:49, sven falempin wrote: >> >>> # pgrep -f "dhclient: vr0 [priv] (dhclient)" >>> # pgrep -f "dhclient: vr0 [priv]" >>> # pgrep -f "dhclient: vr0" >>> 12556 >>> 21826 >>> >>> >>> Where do I kill ? (there is also a few other dhclient running) >> >> >> kill(1) isn't actually required. Try: >> >> # ifconfig vr0 down >> > > === > TL;DR version: it doesn't appear to matter which one gets signaled with HUP, > but I can see that it might make a difference for the other signals. > === > > That actually causes problems if you need the link to stay up while changing > from DHCP to static assignment; my cable modem does weird things every time > it loses carrier on the ethernet side. > Besides, the OP was asking which process to send a signal to when he wants > to control dhclient's behaviour, not just how to terminate the process > outright. > > As it happens, I agree that having a PID file is an "easy" solution for > daemons (like this) that fork and/or modify their proctitle. It's not > entirely clean, as there's no 100%-standard place to put pidfiles, and they > don't always get cleaned up correctly.
well openBSD is so neat it provides a nice call: http://www.openbsd.org/cgi-bin/man.cgi?query=pidfile&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html but i failed to patch :'( this make the dhclient quit instead of going background, the fact there is two process may also explain why there is no pidfile. One is root he other dropped privilege, all of this is just giving me a headache at the moment. Index: dhclient.c =================================================================== RCS file: /cvs/src/sbin/dhclient/dhclient.c,v retrieving revision 1.260 diff -u -p -r1.260 dhclient.c --- dhclient.c 15 Jul 2013 14:03:01 -0000 1.260 +++ dhclient.c 25 Mar 2014 19:50:10 -0000 @@ -61,6 +61,7 @@ #include <poll.h> #include <pwd.h> #include <resolv.h> +#include <util.h> #define CLIENT_PATH "PATH=/usr/bin:/usr/sbin:/bin:/sbin" #define DEFAULT_LEASE_TIME 43200 /* 12 hours. */ @@ -1742,6 +1743,7 @@ void go_daemon(void) { static int state = 0; + char* pidname = NULL; if (no_daemon || state) return; @@ -1762,6 +1764,12 @@ go_daemon(void) close(nullfd); nullfd = -1; } + + if (!asprintf(&pidname, "dhclient.%s", ifi->name)) + error("pidname"); + if (pidfile(pidname)) + error("pidfile"); + free(pidname); /* Catch stuff that might be trying to terminate the program. */ signal(SIGHUP, sighdlr); > The flip side is that correct usage of pkill in the face of proctitle > alterations is far from obvious. Requiring that skill just to signal a > daemon seems to me about as sensible as requiring intimate knowledge of > find(1) just to view a directory listing. > > (...says the guy who still occasionally kills entire systems by accident > when he tries to use pkill for anything complicated. I'm good with find(1), > thanks!) > > On the other hand, dhclient hasn't written a pidfile since 2004 and a > missing pidfile is not exactly a common complaint. > There are two answers: > 1. you can figure out which is the parent/child fairly easily through > ps(1) output. Admittedly this is not trivial to do in a script, but > certainly possible. Also, you only have to figure it out once, then apply > that pattern to "grep". e.g. " PID=$(ps alxww|awk '$3==1 && $13~/^dhclient: > vr0/ {print $2}') > 2. use dhcpcd from ports/packages if you want all the bells and whistles. > > Oh. Actually, now I see sven's point - there are always at least two > processes with PPID=1 and the docs don't specify which one responds to > signals. That's a bug in the manpage, at the very least. > > Sven: you should probably file a bugreport against dhclient for that, the > docs should be clear. Preferably by including a patch, but even just > suggested wording that would make sense to you is good. > > -- > -Adam Thompson > athom...@athompso.net > -- --------------------------------------------------------------------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\
