View Issue Details

IDProjectCategoryView StatusLast Update
0002120unrealircdpublic2005-01-17 14:57
ReporterSineSwiper Assigned Tocodemastr 
Status resolvedResolutionfixed 
PlatformIntelOSSuSe LinuxOS Version20030226
Product Version3.2.1 
Fixed in Version3.2.3 
Summary0002120: SIGINT (or ./unreal restart) does not reload config changes
DescriptionThe "./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 Reproduce1. 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.
TagsNo tags attached.
3rd party modules



2004-10-11 05:59

reporter   ~0007952

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


2004-10-11 06:56

reporter   ~0007956

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.


2004-10-11 15:24

administrator   ~0007958

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 ;).


2004-10-12 03:39

reporter   ~0007982

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.)


2004-10-12 04:25

reporter   ~0007983

Last edited: 2004-10-12 04:26

-9 will force the process to terminate. If you have, then just do kill -9 `cat`.

edited on: 2004-10-12 04:26


2004-10-12 07:03

reporter   ~0007988

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.)


2004-10-12 14:31

administrator   ~0007989

Last edited: 2004-10-12 14:31

Confirmed with the steps you described on latest CVS [.153].
./unreal start
./unreal restart
./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


2004-12-28 23:40

reporter   ~0008685

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


2004-12-29 00:01

administrator   ~0008686

Last edited: 2004-12-29 00:04

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??


2004-12-29 00:42

reporter   ~0008687

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


2005-01-17 14:57

reporter   ~0008837

Fixed in .225

Issue History

Date Modified Username Field Change
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
2005-01-17 14:57 codemastr Status confirmed => resolved
2005-01-17 14:57 codemastr Fixed in Version => 3.2.3
2005-01-17 14:57 codemastr Resolution open => fixed
2005-01-17 14:57 codemastr Assigned To => codemastr
2005-01-17 14:57 codemastr Note Added: 0008837