Hi Robert,

hmm, I like it in principle.

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?

> 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 :)

Although shepherd already has its own /dev/log (syslog) client implementation,
the external "logger" executable (or similar) is still necessary, because
/dev/log is a UNIX domain socket and one can't write to UNIX domain sockets
the same way one does pipes.  Although it might be possible (and not
advisable) to connect() the socket and then dup it to 1 and 2 for the child :P

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.

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.