On 9 May 2014 at 11:15, Michael Orlitzky wrote:

> > [Fri May  9 11:00:42 2014] PAX: refcount overflow detected in: syslog-ng:21823, uid/euid: 0/0

this is the key message, the REFCOUNT feature triggered as it detected
an overflow somewhere.

> > [Fri May  9 11:00:42 2014] CPU: 2 PID: 21823 Comm: syslog-ng Not tainted 3.11.7-hardened-r1 #1

as a sidenote, this is a very old kernel and it's quite possible that
it's a false positive that we fixed since.

> > [Fri May  9 11:00:42 2014] Call Trace:
> > [Fri May  9 11:00:42 2014]  [<ffffffff81052750>] ? 0xffffffff81052750
> > [Fri May  9 11:00:42 2014]  [<ffffffff81036e10>] ? 0xffffffff81036e10
> > [Fri May  9 11:00:42 2014]  [<ffffffff810371e8>] ? 0xffffffff810371e8
> > [Fri May  9 11:00:42 2014]  [<ffffffff810449cc>] ? 0xffffffff810449cc
> > [Fri May  9 11:00:42 2014]  [<ffffffff8100241f>] ? 0xffffffff8100241f
> > [Fri May  9 11:00:42 2014]  [<ffffffff81002a89>] ? 0xffffffff81002a89
> > [Fri May  9 11:00:42 2014]  [<ffffffff8137c212>] ? 0xffffffff8137c212

unfortunately the backtrace is not usable as is due to lack of symbols.
if you still have the original vmlinux around (or can reproduce it with
all the debug symbols) then i can take a look and perhaps figure out
where the refcount overflow was detected (and whether it was a false
positive or not).

> If it's not hardware (two different machines...), does this look like a
> kernel bug? Should I upgrade over the weekend and pray?

it's not a hardware issue (at least not directly) but a software one and
regardless of it being perhaps a false positive you should be using a newer
kernel that we support ;).