OES2SP2 Linux kernel: prune_queue messages

  • 7006643
  • 16-Aug-2010
  • 27-Apr-2012

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.

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.

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.

Feedback service temporarily unavailable. For content questions or problems, please contact Support.