Environment
Novell Open Enterprise Server 2 (OES 2) Linux Support Pack 2
Situation
After applying a number of patches, an increasing number of prune_queue event messages were found in /var/log/messages
For example:
Aug 12 13:17:58 HP-E-7658 kernel: prune_queue: c=4b6223cf
Aug 12 13:30:58 HP-E-7658 kernel: prune_queue: c=dc963c1a
Aug 12 13:31:58 HP-E-7658 kernel: prune_queue: c=dcdce33e
Aug 12 13:32:58 HP-E-7658 kernel: prune_queue: c=4b36f3aa
Aug 12 13:38:58 HP-E-7658 kernel: prune_queue: c=4ac18c28
Aug 12 13:38:58 HP-E-7658 kernel: prune_queue: c=4a7390f7
Aug 12 13:41:58 HP-E-7658 kernel: prune_queue: c=4b6223cf
Aug 12 13:52:58 HP-E-7658 kernel: prune_queue: c=dc963c1a
Aug 12 13:53:58 HP-E-7658 kernel: prune_queue: c=dcdce33e
Aug 12 13:59:58 HP-E-7658 kernel: prune_queue: c=4b36f3aa
Aug 12 14:00:58 HP-E-7658 kernel: prune_queue: c=4ac18c28
Aug 12 14:00:58 HP-E-7658 kernel: prune_queue: c=4a7390f7
Aug 12 14:05:58 HP-E-7658 kernel: prune_queue: c=4b6223cf
Aug 12 14:14:58 HP-E-7658 kernel: prune_queue: c=dc963c1a
Aug 12 14:15:58 HP-E-7658 kernel: prune_queue: c=dcdce33e
Aug 12 14:22:58 HP-E-7658 kernel: prune_queue: c=4ac18c28
Aug 12 14:22:58 HP-E-7658 kernel: prune_queue: c=4a7390f7
Analyzing archived messages files, we found instances of this message going back to February, so this problem has not been introduced with the July 2010 Scheduled maintenance patch.
The output in itself is not very clear as to what daemon or process really is spawning the messages, and although very annoying and making it very difficult to properly read the /var/log/messages file, the message itself is harmless and no functionality will be lost.
For example:
Aug 12 13:17:58 HP-E-7658 kernel: prune_queue: c=4b6223cf
Aug 12 13:30:58 HP-E-7658 kernel: prune_queue: c=dc963c1a
Aug 12 13:31:58 HP-E-7658 kernel: prune_queue: c=dcdce33e
Aug 12 13:32:58 HP-E-7658 kernel: prune_queue: c=4b36f3aa
Aug 12 13:38:58 HP-E-7658 kernel: prune_queue: c=4ac18c28
Aug 12 13:38:58 HP-E-7658 kernel: prune_queue: c=4a7390f7
Aug 12 13:41:58 HP-E-7658 kernel: prune_queue: c=4b6223cf
Aug 12 13:52:58 HP-E-7658 kernel: prune_queue: c=dc963c1a
Aug 12 13:53:58 HP-E-7658 kernel: prune_queue: c=dcdce33e
Aug 12 13:59:58 HP-E-7658 kernel: prune_queue: c=4b36f3aa
Aug 12 14:00:58 HP-E-7658 kernel: prune_queue: c=4ac18c28
Aug 12 14:00:58 HP-E-7658 kernel: prune_queue: c=4a7390f7
Aug 12 14:05:58 HP-E-7658 kernel: prune_queue: c=4b6223cf
Aug 12 14:14:58 HP-E-7658 kernel: prune_queue: c=dc963c1a
Aug 12 14:15:58 HP-E-7658 kernel: prune_queue: c=dcdce33e
Aug 12 14:22:58 HP-E-7658 kernel: prune_queue: c=4ac18c28
Aug 12 14:22:58 HP-E-7658 kernel: prune_queue: c=4a7390f7
Analyzing archived messages files, we found instances of this message going back to February, so this problem has not been introduced with the July 2010 Scheduled maintenance patch.
The output in itself is not very clear as to what daemon or process really is spawning the messages, and although very annoying and making it very difficult to properly read the /var/log/messages file, the message itself is harmless and no functionality will be lost.
Resolution
The root cause for this to happen is that a specific daemon is setting the SO_DEBUG option on a TCP socket.
In order to determine who really spawned the prune_queue message in our case, a special kernel was created that logged the owner of this process. Only using this special kernel we could identify an eDirectory module (libnds) who spawned these messages.
With an updated libnds module it was confirmed that the issue be resolved.
In order to determine who really spawned the prune_queue message in our case, a special kernel was created that logged the owner of this process. Only using this special kernel we could identify an eDirectory module (libnds) who spawned these messages.
With an updated libnds module it was confirmed that the issue be resolved.
Additional Information
The 'out-of-order segment: rcv_next' messages as described in TID 70000074 have the same root cause of SO_DEBUG getting activated in libnds, and will be resolved with the same updated version of this module in a future patch or support pack.