Greetings.
I'm running conserver on Solaris 8 (SPARC), patchlevel MU4.
I compiled conserver as a 32-bit binary using gcc 2.95.3.
Overall, conserver is great. It fscking rocks. However,
it does have one major annoying behaviour in my environment:
when you kill the conserver daemon, either via in-band kill
from a 'console' client or via the 'kill' command, it does
NOT correctly relinquish the TCP port it had been listening
on. In my case, it's tcp/782.
This is really ugly because the port hangs around in TIME_WAIT
for a long time (>5 minutes on my systems) and I can't restart
the conserver daemon until the timeout expires. Clearly, this
makes restarting conserver something you don't want to do
unless you *really* have to. It probably goes without saying,
but being able to 'kill -HUP' the daemon to cause a reread of
the config file would be a Very Good Thing.
Has anyone else seen this behaviour, or is it just me?
-Trevor
--
Trevor Fiatal -- trevor@seven.com -- http://www.seven.com/
Co-Founder
Seven
I'm running conserver on Solaris 8 (SPARC), patchlevel MU4.
I compiled conserver as a 32-bit binary using gcc 2.95.3.
Overall, conserver is great. It fscking rocks. However,
it does have one major annoying behaviour in my environment:
when you kill the conserver daemon, either via in-band kill
from a 'console' client or via the 'kill' command, it does
NOT correctly relinquish the TCP port it had been listening
on. In my case, it's tcp/782.
This is really ugly because the port hangs around in TIME_WAIT
for a long time (>5 minutes on my systems) and I can't restart
the conserver daemon until the timeout expires. Clearly, this
makes restarting conserver something you don't want to do
unless you *really* have to. It probably goes without saying,
but being able to 'kill -HUP' the daemon to cause a reread of
the config file would be a Very Good Thing.
Has anyone else seen this behaviour, or is it just me?
-Trevor
--
Trevor Fiatal -- trevor@seven.com -- http://www.seven.com/
Co-Founder
Seven