Description of problem: I've just upgraded my gateway from f13 to 14 and to bind-9.7.4-0.3.b1.fc14.x86_64. For the most part all is well. However named child processes are writing messages repeatedly to named.run (if I configure logging as per default config), or simply trying to write (if I don't) and either way doing it do quickly it's taking over 50% cpu of a modern dual core server. Unless I impose a file size limit on named.run the file grows to multiple gigs in an hour or so. How can I stop it doing this? There doesn't seem to be any useful work being done... The messages are: zone_timer: managed-keys-zone ./IN: enter zone_maintenance: managed-keys-zone ./IN: enter zone_settimer: managed-keys-zone ./IN: enter zone_timer: managed-keys-zone ./IN: enter zone_maintenance: managed-keys-zone ./IN: enter zone_settimer: managed-keys-zone ./IN: enter If I do an strace on named with "forked children" too (with named.run logging enabled) I get loads of: [pid 3556] <... futex resumed> ) = 1 [pid 3556] stat("data/named.run", {st_mode=S_IFREG|0644, st_size=5242884, ...}) = 0 [pid 3556] stat("data/named.run", {st_mode=S_IFREG|0644, st_size=5242884, ...}) = 0 [pid 3556] stat("data/named.run", {st_mode=S_IFREG|0644, st_size=5242884, ...}) = 0 [pid 3556] futex(0x7fa5aab8907c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7fa5aab89078, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1} <unfinished ...> [pid 3558] <... futex resumed> ) = 0 [pid 3558] futex(0x7fa5aab89028, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...> [pid 3556] <... futex resumed> ) = 1 [pid 3556] futex(0x7fa5aab89028, FUTEX_WAKE_PRIVATE, 1 <unfinished ...> [pid 3558] <... futex resumed> ) = 0 [pid 3558] futex(0x7fa5aab89028, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 3558] futex(0x7fa5aab8907c, FUTEX_WAIT_BITSET_PRIVATE| FUTEX_CLOCK_REALTIME, 20131209, {1316174566, 812856000}, ffffffff <unfinished ...> How reproducible: Always Steps to Reproduce: 1. Run it.
Please check https://bugzilla.redhat.com/show_bug.cgi?id=709205#c7 for workaround (put managed-keys-directory "/var/named/dynamic"; into your named.conf) *** This bug has been marked as a duplicate of bug 709205 ***