View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002120||unreal||ircd||public||2004-10-11 05:48||2005-01-17 14:57|
|Platform||Intel||OS||SuSe Linux||OS Version||20030226|
|Target Version||Fixed in Version||3.2.3|
|Summary||0002120: SIGINT (or ./unreal restart) does not reload config changes|
|Description||The "./unreal restart" command is misleading and doesn't work as expected. Apparently, a SIGINT doesn't actually reload the config file. I noticed this when I tried a stop & start, and suddenly I couldn't log in. (This was due to a recent screw up on my allow blocks.)|
After experimenting with config changes using a stop & start, it would actually reload the config this time.
This was reproducable with both allow and oper block changes. I was having oper block problems at the time, and this bug was seriously confusing the issue. Furthermore, the restart doesn't even kick you out of your session, so it makes me wonder if it's even doing anything.
|Steps To Reproduce||1. Make change to config. Try a oper block change (different password).|
2. Run "./unreal restart" on the shell.
3. Jump out of IRC session (if existing), and log back in.
4. Try /oper command with new password. It should fail.
|Tags||No tags attached.|
|3rd party modules|
||hmmm, i noticed this before, except it was related to reloading modules and i thought 'hmmm, just musnt do that', so i changed restart to do $0 stop and $0 start|
I've noticed that there's a "rehash" option that gives it a SIGHUP, and that DOES reload the config. However, "restart" is traditionally mean to "reload the config" (among other things). Daemons like inetd and Apache behave that way.
I'm still puzzled what the SIGINT actually does, though.
I cannot reproduce that here, things like changing the oper password works fine here. It would have been quite weird anyway, since restart/SIGINT does just that.. it restarts the ircd (=the ircd spawns a new ircd instance and the old one commits suicide).
> 3. Jump out of IRC session (if existing), and log back in.
Ahh.. Well you(&everyone else) should have been disconnected since the whole ircd restarted. If that didn't happen, then that is the problem ;).
This is very bizzare. I can try a "kill -2 [pid]" just fine, and it actually restarts the way it should. But, if I do a "kill -2 `cat $PID_FILE`" (after exporting PID_FILE), it doesn't do anything. However a "kill -9" using the backreference works just fine and kills my IRC server.
Therefore, it's not really the PID file, and it's not really the command. Weirder still, I try the second command again, and then it DOES work. I do it two more times and nothing happens. Now I try "kill -2 13288" and that doesn't work either. (Yes, I've been confirming the PIDs the whole time.) The "kill -SIGINT 13288" doesn't work either.
I can still type in the IRC session. I started my services up (Anope), and it still works. Went back to a kill -2 (and -SIGINT) command with no result.
So, is unreal trapping the SIGINT signal the wrong way or with a low priority? Something quirky with bash's kill command? (I would think not...I don't think it's been touched for years.)
-9 will force the process to terminate. If you have ircd.pid, then just do kill -9 `cat ircd.pid`.
edited on: 2004-10-12 04:26
I know how that works. It's just that the SIGINTs are behaving erratically. I think it's a problem with the SIGINT program trap. SIGTERM doesn't have a trap (or has a well-behaved trap) and it works every time. (SIGKILL, which is what the stop command uses, is untrappable.) I think I found a proper set of reproducables, though:
1. Stop the server with SIGTERM/KILL.
2. Start the server. You'll get a PID that we'll call A.
3. Use a SIGINT to restart the server. The new PID = B.
4. Now, try -another- SIGINT on PID B. You can SIGINT until you're blue in the
face, but the PID doesn't change.
For some reason, it seems like the SIGINT trap is keeping some PID-related variable that it forgets to change when it respawns on step #3. Thus, it considers the action invalid (or some other 'if' check), and doesn't do it the second time.
This is consistant behavior I'm getting on my server. I'm not sure if it's universal, but it seems hard to believe that it isn't. (After all, there's no config entry that would change that, and the 'kill' command is the same thing among distros.)
Confirmed with the steps you described on latest CVS [.153].
./unreal restart <-- has no effect (even tried multiple times)
Oh, and I also tried kill -2 <pid-of-ircd> of course, didn't work either.. odd ;).
edited on: 2004-10-12 14:31
digging around as this got reported with anope as well, it came down to a reference in the man pages out there
execv*() does not return on success, and the text, data, bss, and stack of the calling process are over-written by that of the program loaded. The program invoked inherits the calling process's PID, and any open file descriptors that are not set to close on exec. Signals pending on the calling process are cleared. Any signals set to be caught by the calling process are reset to their default behaviour. The SIGCHLD signal (when set to SIG_IGN) may or may not be reset to SIG_DFL.
So far haven't found a way to get the signals to the new (child) process, it will respond to SIGCHLD but nothing else.. hope this puts some light on this
Well, what you pasted seems logical to me (unless I misread it).
But since we setup all signals again in main(), I don't know what the problem is.
PS: I never heard (nor experienced) that the PID would stay the same??
So does Anope, we setup the signals are as we init, I have tried posix and bsd style signals, I can put debugs around them and watch them set, and map all the signals to a debug function to look at message and then sit there and loop and watch stuff like SIGINT and SIGHUP get ignored
Another man reference to execv functions says
"Signals set to be caught by the calling process image shall be set to the default action in the new process image"
If I come up with something I will post it.. but so far haven't had much luck
|Fixed in .225|
|2004-10-11 05:48||SineSwiper||New Issue|
|2004-10-11 05:59||Neo-Vortex||Note Added: 0007952|
|2004-10-11 06:56||SineSwiper||Note Added: 0007956|
|2004-10-11 15:24||syzop||Note Added: 0007958|
|2004-10-12 03:39||SineSwiper||Note Added: 0007982|
|2004-10-12 04:25||al5001||Note Added: 0007983|
|2004-10-12 04:26||al5001||Note Edited: 0007983|
|2004-10-12 07:03||SineSwiper||Note Added: 0007988|
|2004-10-12 14:31||syzop||Note Added: 0007989|
|2004-10-12 14:31||syzop||Status||new => confirmed|
|2004-10-12 14:31||syzop||Note Edited: 0007989|
|2004-12-28 23:40||trystanscott||Note Added: 0008685|
|2004-12-29 00:01||syzop||Note Added: 0008686|
|2004-12-29 00:04||syzop||Note Edited: 0008686|
|2004-12-29 00:42||trystanscott||Note Added: 0008687|
||Status||confirmed => resolved|
||Fixed in Version||=> 3.2.3|
||Resolution||open => fixed|
||Assigned To||=> codemastr|
||Note Added: 0008837|