I guess what I'm proposing is not a specific workaround but a way for legacy software which can only log to a file to get it's data into journald. There is plenty of software like that, unfortunately. It's a pragmatic option.
In this specific case, I'm referring to Nginx in daemon mode, which closes /dev/stderr as far as I can tell, and then spawns passenger, which can only log to a file. There is no way to hook up passenger to /dev/stderr. The proposed service allows anyone to set up a fifo for logging in this situation, it's very trivial and easy to set up, but I suspect there is more than just one person with this issue. On 12 April 2016 at 02:21, Lennart Poettering <mzq...@0pointer.de> wrote: > On Sun, 10.04.16 22:57, Samuel Williams (space.ship.travel...@gmail.com) > wrote: > > > Hello, > > > > > > I've been trying to figure out the best way to support legacy > applications > > that don't support syslog for logging. The best we can do, I think, is to > > use fifo and have another process read the fifo to journald. > > Note that on systemd everything logged out stdout or stderr ends up in > the journal anyway. And you can specify /dev/stderr or /proc/self/fd/2 > as path referring to stderr on Linux generally, if you need. > > > Finally, if this is a good approach, is this method worth putting into > > systemd/journald as a standard service? If so, how do I submit a PR or > > where to begin? > > Specific work-arounds around other, unrelated pieces of software are > not really what we we'd like to add to systemd directly. Sorry. > > Lennart > > -- > Lennart Poettering, Red Hat >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel