-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Anand,
On 01/28/2014 02:16 PM, Anand Buddhdev wrote:> I've noticed that when NSD shuts down, it can be a bit messy.
> Here's an example:
>
> [1390913907] nsd[22966]: warning: signal received, shutting
> down... [1390913907] nsd[22966]: warning: rmdir
> /var/lib/nsd/nsd-xfr-1093 failed: Directory not empty [1390913908]
> nsd[1093]: warning: rmdir /var/lib/nsd/nsd-xfr-1093 failed:
> Directory not empty [1390913932] nsd[23003]: info: zone
> 96.147.in-addr.arpa. received update to serial 2014012801 at
> 2014-01-28T12:58:23 from 193.0.0.198 TSIG verified with key
> ripencc-20110222 of 1026966 bytes in 0.202617 seconds
>
> Notice that processes 22966 and 1093 (1093 is the main process)
> both tried to delete a directory which contained an incoming zone
> transfer, and failed. This incoming zone transfer was being
> processed by process 23003.
>
> When I killed 1093, it exited almost immediately, and did not wait
> for any of its children. In particular 23003 continued running for
> 24 more seconds, and only exited after applying the zone transfer
> to the database.
>
> This is problematic, because when I killed 1093, and it exited, as
> far as I was concerned, NSD was completely shut down, and I could
> restart it, or do other housekeeping. But one NSD process was still
> running. Additionally, that last process, after applying its zone
> transfer, did not remove the directory /var/lib/nsd/nsd-xfr-1093,
> so that directory is now hanging around.
>
> Is there any reason the master process does not wait for its
> children to finish before exiting?
We did update it in NSD4 for precisely this issue, but then for the
'server' processes. The process that has the issue now is the reload
process. I'll have to take a good look at how I can make that one
stop earlier (without trashing the nsd.db file). Likely, you'll have
to wait for 10-20 seconds in your case before it manages to kill off
that long running reload process.
This reload process was handling a zone transfer in that directory,
which is why it was not empty. Thank you for that report, it explains
earlier observations of the directory not empty.
Best regards,
Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS56+ZAAoJEJ9vHC1+BF+NbOYQAK5xbIPOBbdmcy848/pmlrVH
xFkij/pZS5xFIoSst+Lf8bfxqXfrQwhhAKza6ZK+Yu2Fe/bbyaPnDaczFdB4i1tN
EuXP2z6/sHn100Uanz4H0PfMOsAq0kwtfkO+ci51o0CdyxLcEXcj/dJHpwypGd2p
bGmpw8NrL4phpeWd1EVyx+wF8R+B4LXiFGJNWLDJlFLpi/6CipeltWqk45O8R3pF
mSDE3LQuSlb+1xWrg5bx4p9grAceCxjvsrH+XMfM5wSDubl40BbqlSB6jOfsdfYV
xNZR/wlV7tVq5wwNxAAepVxc7dUwsF1NGwX5TSTEV+7PhhGjDGeukmcUPNiQSVWU
xfVMES90TQOfbVLKhsZySZi1jO6GDqI334oAbmeaHYoU0B38BThqGCBI+p6v9szt
ap2RGlaJ3nP8VTVBo+u49erWZhrDqNeIQZffbb7ATTBg2mbR05v+TFrzna72nenv
Y8XJYGe93q1/bUTpTx0STBGgYw6KuGiqK5QPgH9b53A3oVS/UfLrCjm3nVSJlXjm
5Zcxn+Lo0INpvNgMaUNsHYHZsb91TIijNoev5/vRQURxDjH8c0ukGsi6qgqIfnzq
VBVEG4JAripBzmVZ1SR7BxKSrcucOkk0xmQF2/vxYIj+hRnfoi0KK4CA6yHL0QIb
gmSaP9FGTyEUcOpv63yT
=sU5q
-----END PGP SIGNATURE-----