22

I have one particular service, that logs rare, but important information. I've set it up few months ago, and today I've run journalctl -n 50 --unit=my-service only to find there are no entries.

I'm perfectly happy with this behavior for most units — I either need something that happened right away (or few days ago at most), and I don't care about months-old records.

However, is there a way to tell journald to have an independent storage and retention policy for a single particular unit's records? I want to persist those particular logs for, say, 5 years — no matter the size it would take. The other units' logs should be unaffected by this, and retain their existing behavior.

I'm sort of lost understanding journald.conf(5), and can't figure out whenever per-unit configuration is possible at all. If it is — would appreciate a brief concrete example - which file should I edit/create and what should I write. Or, if you know for sure it's certainly not doable — that would be a good answer as well.

NOTE: My particular case involves Arch Linux host, but I guess this shouldn't matter much.

Improve this question
1

2 Answers 2

Reset to default
9

Seems that I'm most likely out of luck with journald. Unless I'll figure out a way to spawn a independent "long-term storage" journal (like currently there are different per-user journals), but I'm not sure it's a viable and sane approach. I guess, setting up a syslogd (and logrotate) would be easier.

The feature wasn't present in late 2014, as confirmed by Lennart himself.

And it seems that it's not here yet. At least, the line "journald: allow per-priority and per-service retention times when rotating/vacuuming" is still in the TODO file (link to revision from 2016-07-11).

Improve this answer
4
  • 5
    This seems like a very big design flaw, almost crippling. Especially if one wants to decrease retention or at least log level of very chatty units, which clog up the logs.
    – orion
    Commented Jan 20, 2017 at 13:29
  • 2
    For anyone stumbling upon this question, the referenced line in the TODO is still present as of this comment (26.03.18): github.com/systemd/systemd/blob/…
    – timss
    Commented Mar 26, 2018 at 9:58
  • 2
    In an attempt to get some traction on it I raised it as a issue with the project - github.com/systemd/systemd/issues/9519.
    – slm ♦
    Commented Jul 6, 2018 at 21:14
  • Looks like we can now use log namespaces to achieve different retention for different services: github.com/systemd/systemd/issues/9519#issuecomment-1919751722
    – Rogach
    Commented May 2 at 3:40
3

It is remarkably simple to generate the log file. By default all logging to journald goes to syslog as well and this default needs to be in place. The rsyslog.conf controls how the entries passed to syslog are handled. In addition the SyslogFacility defaults to daemon so the log entries for any service usually end up in the daemon.log file in /var/log.

In your service file add to the [service] section 

SyslogFacility=local2

(the number can be between 0 & 7) https://www.freedesktop.org/software/systemd/man/systemd.exec.html

Modify the /etc/rsyslog.conf (find the existing lines to modify) so that local2 is logged to a specific file (first line) and ideally not logged to syslog by adding local2.none as shown (it is already in the journal).

local2.*                        /var/log/your-service-name.log
*.*;auth,authpriv.none,local2.none          -/var/log/syslog

[edit] you also need to amend the catch all

*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none,local2.none      -/var/log/messages

Of course the actual retention then needs to be done by logrotate.

HTH

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .