On Tue, Sep 16, 2025 at 11:32:33AM -0400, Steve Litt wrote:
> aitor said on Tue, 16 Sep 2025 16:47:04 +0200
>
> >I thought that "/run/user/$UID" was created by pam-systemd, but this
> >directory already exists in my devuan system.
>
> My Void Linux system has /run/user already, and it would be simple to
> create a /run/user/slitt directory that's owned by slitt. Below that I
> could have /run/user/slitt/fetchmail, /run/user/slitt/pulseaudio,
> /run/user/slitt/pager, etc. This would certainly work and is certainly
> reasonable, always assuming /run is on a partition big enough to
> accommodate growing log files.
>
It is not for reasons mentioned down-list, though the primary reason
other than /run being a tmpfs is that the lifecycle of /run/user/$UID is
specified in the XDG_RUNTIME_DIR documentation as being the same as the
longest login session for a given user. In other words, when you close
your final login session the directory is supposed to be wiped. This
lifecycle is generally assumed to be managed by PAM, but that's a
guideline not a rule.
> As more and more people write me with suggestions, it seems to me that
> the answer is "it depends".
>
This is the way, though the "it depends" has more to do with the
expected lifecycle of the service than any sort of question as to where
the logs should end up.
> From my perspective, the first question to be answered is whether I
> want my logs to be in the same tree as my data, and backed up with my
> data. In my case, the answer is "no". So, like some people have pointed
> out, I personally am not going to have my logs anywhere in the /home
> tree.
>
The only rule is, as always, that the thing exists as is writable before
you start writing to it. If your service dirs are on NFS, it's entirely
fine to also put your logs on NFS as there is no way for your scanner to
find, or a supervisor to manage, something before it is available.
> Somebody suggested putting it in the /var/log/slitt/fetchmail, etc,
> with the proper directory ownership and permissions. This is certainly
> an expected place, very similar to /run/user/slitt/fetchmail, except
> that /var/log is where log files are expected, so it's presumably sized
> for them and easy to remember and find.
>
This is the most appropriate for long-lived services with a lifecycle
that's larger than a login session and is also fine for things with a
per-login lifecycle such as a sound server on a non-headless system.
> If I person *does* consider the logs data, then something in /home is
> certainly a great idea. Djb's putting them under
> $servicedir/fetchmail/log/logs has a nice expectancy to it.
>
I personally hate the DJB convention but that's because it's messy and I
don't like mixing things that are the purview of the supervisor (the run
script, supervise directory, stuff like that) and diagnostic and
informational data (logging). It also doesn't work for my general setup
because I launch my supervision tree against a copy in /run and for
reasons we discussed that won't survive past a reboot.
> And of course, a whole different school of thought is that you should
> just feed the logs to whatever logging system is running on the
> computer, which has the advantage of showing this daemon's events in
> time context with other events, and the disadvantage of having this
> daemon's events scattered and hard to find.
>
This is how you get a bad case of venereal syslog and the topical cream
for that is very expensive.
> In my documentation I think I'll need to discuss that this is a decision
> based on the situation. In my particular use case, I don't want these
> logs backed up at all, so I might end up putting them under my /scratch
> tree, which specifically does not get backed up.
>
> I really value all the opinions you and everyone else is giving me.
> Based on the responses, I think there's no one-size-fits-all right
> answer, and that's something I wouldn't have realized if not for yours
> and other peoples' input.
>
The most "unix normal" approach would be /var/log/USER/SERVICE and the
most "it really only matters to the user" would be something under
$HOME. All other approaches are situationally viable at best and have
really nasty downsides if you don't manage them correctly.
--
Colin Booth
Received on Wed Sep 17 2025 - 19:43:48 CEST