I'm at the point in my #NixOS adventures that the language is starting to frustrate me enough to reconsider using #Guix instead, and accept that I'll have to drop or rewrite all the little things I built upon systemd.

One of the bigger problems with that, is that I rely on the systemd Journal a lot, including the fact that services started will have their stdout available in the journal.

If I abandon systemd, I'll have to come up with something similar for shepherd (if it doesn't already have something like that - I haven't finished reading the manual yet), because just logging to stdout is mighty convenient. I'm not parting with that luxury.

Okay, looks like stdout and stderr can be redirected to a file, that's great. I wonder if the log file can be a pipe? Almost like /dev/log, just not terrible.

@algernon didn't /dev/log expect syslog format though? IIRC the pre-systemd way was to pipe stdout/stderr to logger(1) with options for severity, facility etc. but I haven't done this myself and I don't know how feasible that'd be with shepherd....

@wolf480pl It does, hence "almost like /dev/log but not terrible" :)

Basically, if I can set the log file to a pipe, I'll set it to one where the other end is a custom daemon I write, which does a whole bunch of things like discovering the process on the other end, some basic info about it, and store the message in-memory. Pretty much what the Journal does, without the parts I don't need from it.

Follow

@algernon pretty sure a pipe wouldn't let you do that, but a unix socket should do.

@wolf480pl Ooof. Brain fart on my part. I wanted to write unix socket, not pipe. Thanks!

@algernon oh, also, getting a PID through SO_PEERCRED and then looking up properties of that process in /proc/$pid is race-y, but I guess for the purpose of logs it isn't that big of a problen

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!