Lusca/Squid getting a SIGHUP and running reconfigure at startup

[GoogleCodeExporter]

I found a wierd startup behaviour.

_ALWAYS_ after cold start (machine boot) reconfigure() is automatically 
called after cleanup

shutting squid down and starting again not

start|stop is done by the same rc.d init script

here the relevant (... means I cut stuff):

2010/04/05 02:24:25| Starting WebCache on amd64-unknown-freebsd8.0 ...
...
2010/04/05 02:24:26| Loaded Icons.
...
2010/04/05 02:24:26| Process id written to pid file.
2010/04/05 02:24:26| Network Connections ready to serve requests.
2010/04/05 02:24:26| Starting Cleanup procedure ...
...
2010/04/05 02:24:27| Finished rebuilding storage from disk.
..
2010/04/05 02:24:27| Beginning Validation Procedure
>>>>>> look this:
2010/04/05 02:24:27| I'm here: reconfigure() set do_reconfigure=1 ...
2010/04/05 02:24:27|   Completed Validation Procedure
2010/04/05 02:24:27|   Validated 59557 Entries
2010/04/05 02:24:27|   store_swap_size = 1595874k
2010/04/05 02:24:27| finished cache_dir double check (by -S option).
2010/04/05 02:24:27| WebCache finished storeCleanup ...
2010/04/05 02:24:42| I'm here: main loop calling mainReconfigure ...
2010/04/05 02:24:42| Reconfiguring WebCache ...
...
2010/04/05 02:24:43| Loaded Icons.
2010/04/05 02:24:43| Process id written to pid file.
2010/04/05 02:24:43| Network Connections ready to serve requests.
2010/04/05 02:24:43| Reconfiguring WebCache done, ready to go ...
2010/04/05 02:24:43| I'm here: main loop do_reconfigure = 0 ...
2010/04/05 02:24:43| storeLateRelease: released 0 objects
2010/04/05 02:24:43| All Startup Procedures finished, the WebCache is 
ready to
go.

Original issue reported on code.google.com by hm@hm.net.br on 5 Apr 2010 at 10:14

[GoogleCodeExporter]

hm runs a custom Lusca build with some tproxy patches but he tells me it 
happens with
a clean, non-tproxy patched Lusca.

He also mentioned that it happens only at startup. It doesn't happen if he 
manually
runs the startup scripts himself.

It doesn't occur on my local FreeBSD-8.0-p2 amd64 box with the lusca-head port.

I had a theory - that SIGHUP is being received shortly after startup because of
SIGHUP being sent to the process group.

A bit of digging showed that Lusca doesn't disassociate from the current process
group and create its own if it's run with the -N (no daemon) flag.

I asked him to add a call to setsid() at the beginning of mainInitialize(). This
fixed his issue.

The question now is why -his- setup is generating process group SIGHUP's which 
aren't
appearing elsewhere.

Original comment by adrian.c...@gmail.com on 5 Apr 2010 at 10:19

• Changed state: Accepted
• Added labels: Version-Head
• Removed labels: Version-1.0