View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002120unrealircdpublic2004-10-11 05:482005-01-17 14:57
ReporterSineSwiper Assigned Tocodemastr 
PrioritynormalSeveritymajorReproducibilityalways
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

Activities

Neo-Vortex

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

SineSwiper

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.

syzop

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

SineSwiper

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

al5001

2004-10-12 04:25

reporter   ~0007983

Last edited: 2004-10-12 04:26

 -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

SineSwiper

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

syzop

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

trystanscott

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

syzop

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

trystanscott

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

codemastr

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