Description of problem:
OpenBSD added new sendsyslog(const char *, size_t) system call which simply passes a message up into syslogd's /dev/log interface. This will be used to make syslog_r work during file descriptor exhaustion, or inside sandboxes which
prohibit socket, connect, sendto, etc.
The system call is being added about a week before the library and daemon
It would be neat to have such thing in Linux kernel too. It would help logging in chroots (not mount --bind or other "tricks).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I don't think that having a syscall is the right approach here.
Bind mounting directories or sockets into chrooted or container environments has really become the defacto solution here. The advantage is that it put the host in control over the logging. If the host doesn't want the container to log, it just doesn't set up the container-to-host logging bridge.
Many projects are building in systemd journal support like "systemd-nspawn --link-journal" and "docker --log-driver=journald"
This would face an additional challenge of acceptance upstream.
I believe the majority belief on this topic is that the container manager (docker, systemd-npsawn) should be responsible for setting up the logging.
If you agree, we can close. If not, please elaborate on the situation in which you think that this is the best solution.
Benefit of OpenBSD solution is logging would work even one would be out of FDs. Do whatever you want with this BZ.
(In reply to Jiri Belka from comment #5)
> Benefit of OpenBSD solution is logging would work even one would be out of
True, but I see that being a rare case. Probably means your system is either misbehaving or compromised :) Either way, I don't see that being enough justification upstream.