> On 17. Jun 2019, at 14:45, Danny Milosavljevic <[email protected]> wrote: > > But doesn't shepherd already log to /dev/kmsg and/or /dev/log (so that ends up > in syslog)? Since exec-command&co keep the standard output and standard > error, > they (and thus all shepherd services) should also already log to the > aforementioned syslog by default. > > What is the use case you envision?
It sure doesn’t seem like it. For that service, everything lands on /dev/console, and I even see some sshd messages there that don’t make it to syslog... >> Would logger-wrapper be generally useful to have available? If so, >> is it named well, and where would it fit? > > I think it could be made part of shepherd and be exported there, then everyone > could use it. Logging to syslog isn't exactly an obscure requirement :) Oh I agree that shepherd should in principle deal with capturing stdout/stderr. I rather like how systemd‘s status command shows the last few lines of process output. Just not sure this kind if wrapper fits there. > P. S. The way you invoke logger (without full path or gexp package reference) > it will pick up a random logger implementation. I'm surprised that it works > at all that way. I didn’t figure out how else to refer to it. It’s part of bsdutils upstream as far as I can tell, and installed by default. > P. S. Your implementation has shell injection because "name" could contain > spaces and/or semicolons. I suggest not to use the shell command string but > rather passing logger's argv directly. Ok, will try to figure out how to open pipes with explicit argv. Thanks Robert
