Bug 1121563

Summary: [RFE] sendsyslog system call which simply passes a message up into syslogd's /dev/log interface
Product: Red Hat Enterprise Linux 7 Reporter: Jiri Belka <jbelka>
Component: kernelAssignee: Seth Jennings <sjenning>
kernel sub component: Kernel-Core QA Contact: Red Hat Kernel QE team <kernel-qe>
Status: CLOSED WONTFIX Docs Contact:
Severity: unspecified    
Priority: unspecified CC: jbelka
Version: 7.2Keywords: FutureFeature
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-12 15:39:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jiri Belka 2014-07-21 08:47:19 UTC 
Description of problem:
OpenBSD added[1] 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
changes.

It would be neat to have such thing in Linux kernel too. It would help logging in chroots (not mount --bind or other "tricks).

[1] http://marc.info/?l=openbsd-cvs&m=140498255523068&w=2

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 4 Seth Jennings 2015-11-09 21:44:14 UTC 
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.
Comment 5 Jiri Belka 2015-11-12 08:53:56 UTC 
Benefit of OpenBSD solution is logging would work even one would be out of FDs. Do whatever you want with this BZ.
Comment 6 Seth Jennings 2015-11-12 15:39:16 UTC 
(In reply to Jiri Belka from comment #5)
> Benefit of OpenBSD solution is logging would work even one would be out of
> FDs.

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.