RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1121563 - [RFE] sendsyslog system call which simply passes a message up into syslogd's /dev/log interface
Summary: [RFE] sendsyslog system call which simply passes a message up into syslogd's ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Seth Jennings
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-21 08:47 UTC by Jiri Belka
Modified: 2018-10-12 20:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-12 15:39:16 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.