>> Not syslog, but helps with debugging... > That definitely helps - however, in the long run, I think that using syslog > is better.
I agree, but someone has to write it... > Syslog does the splitting up in different files (or not) and onto different > machines > (or not), filtering (or not), log rotation etc. So it makes sense to make > services > use syslog instead of rolling-your-own filtering, splitting, networking > etcetc 267843 > times. I don't intend to reimplement any of this. I just needed a way to dump stuff to a file instead of a tty. It's intended for usage during development of services, not for deployment. As Ludo mentioned it's not quite as simple as just redirecting stdout/sderr and needs some support in shepherd. Someone who actually runs services that require high availability will have to contribute better logging support ;) > That said the services should just use syslog on their own Many services expect stdout/stderr to be handled. I don't think that every service needs to reimplement basic logging functionality. systemd allows to set a services stdout and stderr to either journal/syslog/file/tty, so new services written for systemd expect this to be taken care of. > we could only guess when a new log message starts New lines are a pretty good guess.
