#513880 Optionally omit timestamps from lines sent over UDP

Package:
socklog
Source:
socklog
Description:
system and kernel logging services - binaries
Submitter:
Andras Korn
Date:
2026-03-08 16:27:02 UTC
Severity:
wishlist
Tags:
#513880#5
Date:
2009-02-01 23:50:28 UTC
From:
To:
Hi,

when logging kernel messages over UDP with socklog+svlogd, the end result
looks like this:

@400000004986304d23ededec 172.18.17.254: @400000004986304d23676c54 kern.warn: Feb  2 00:29:07 kernel: ...

The line contains three timestamps, which is not very useful and only makes
the message harder to read. I know I can do the following:

1. get rid of the first timestamp by not telling svlogd on the logserver to
   log one;

2. get rid of the second timestamp by not telling svlogd on the client system
   to log one.

The problem with #1 is that some syslog clients send timestamps whereas
others don't, and I need to have timestamps enabled in svlogd on the server
for the sake of the latter.

The problem with #2 is that the client also writes the logs to local storage
and I definitely want the timestamps there.

I can see the following options:

1. Adding a new config command to "send via UDP without timestamp".

2. Making timestamps toggleable on a per-directory basis (I could have a
   logdir with only udp targets and no timestamps and other logdirs with
   no udp targets and timestamps enabled).

3. Some mangling on the server side to recognise a tai64n timestamp at the
   beginning of the incoming line, and insert the client IP field after it
   instead of in front of it. This seems somewhat kludgy to me even though
   it would probably work very well in practice.

This still doesn't get rid of the third, useless, syslog-style timestamp,
but I guess you wouldn't want to add sed-style editing functions, and I
can't really see any other way. :)

Andras
#513880#10
Date:
2020-11-08 22:56:46 UTC
From:
To:
Dear all,

As maintainer of socklog I am taking the liberty of closing this 10
years old bug to clean the backlog. Please feel free to re-open if you
disagree.

Cheers,
#513880#17
Date:
2020-11-09 22:45:08 UTC
From:
To:
Sure, I understand, combining syslog-ng and socklog is not ideal.

However I don't think that the debian package is the right place to
implement the features that you suggest. Best would be to contact
upstream (ideally with a patch) and see if he's interested in adding
that to socklog and/or svlogd. In this case I would be more than happy
to package the new version. One release per decade is something I can
easily sustain :)
#513880#22
Date:
2026-03-07 20:57:30 UTC
From:
To:
Dear Andras,

<korn-debbugs@elan.rulez.org> wrote:

[ snip ]

[16 years later]

In case this is still relevant now, could you please take a look at the
patch that was recently merged in upstream next branch at

https://github.com/g-pape/socklog/pull/6

https://github.com/g-pape/socklog/commit/a2bc68f1e46693d76500405489832ef7b9096bf0

and tell if it would fix this bug? (I think it does)

I can add the patch to the Debian package in case a new release doesn't
happen soon.

Best,
Lorenzo
#513880#29
Date:
2026-03-08 16:18:17 UTC
From:
To:
On Sat, Mar 07, 2026 at 09:57:30PM +0100, Lorenzo wrote:

Hi,

17, even :)


I'm using syslog-ng in these situations, so while I approve of this change in general terms, it wouldn't have an immediate impact for me. I appreciate the offer to backport the patch, but there is no need.

Thanks!

András