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 1209162 - RFE: CustomLog should be able to use journald
Summary: RFE: CustomLog should be able to use journald
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: httpd
Version: 8.3
Hardware: All
OS: Linux
Target Milestone: rc
: 8.3
Assignee: Luboš Uhliarik
QA Contact: Branislav Náter
Lenka Špačková
Depends On:
Blocks: 1298243 1473733 1562205 1630916 1654421
TreeView+ depends on / blocked
Reported: 2015-04-06 14:22 UTC by Pat Riehecky
Modified: 2023-12-15 15:49 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
.Support for logging to `journald` from the `CustomLog` directive in `httpd` It is now possible to output access (transfer) logs to `journald` from the Apache HTTP Server by using a new option for the `CustomLog` directive. The supported syntax is as follows: ---- CustomLog journald:priority format|nickname ---- where _priority_ is any priority string up to `debug` as used in the link:http://httpd.apache.org/docs/2.4/mod/core.html#loglevel[`LogLevel` directive]. For example, to log to `journald` using the the `combined` log format, use: ---- CustomLog journald:info combined ---- Note that when using this option, the server performance might be lower than when logging directly to flat files.
Clone Of:
: 2024310 (view as bug list)
Last Closed: 2020-11-04 03:35:12 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Apache Bugzilla 54796 0 None None None 2019-07-29 11:35:42 UTC

Description Pat Riehecky 2015-04-06 14:22:29 UTC
Description of problem:

mod_log_config doesn't allow to use syslog facility like this:

CustomLog syslog:local4

(like it's possible with ErroLog).

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

How reproducible:

Steps to Reproduce:
1.Try to use the syslog syntax provided by ErrorLog on CustomLog

Actual results:
Does not work

Expected results:
Can use native syslog capabilities

Additional info:

Comment 2 Joe Orton 2015-04-07 09:01:45 UTC
Pat, please file a ticket with support for this kind of RFE.  It looks like quite a bit of work is required to get this integrated (including upstream) and so we need a business justification for that.

Comment 3 Pat Riehecky 2015-04-07 13:06:25 UTC
It looked like the upstream bug has a patch for the relevant behavior.

I'll reach out for getting an appropriate support case file.

Comment 6 Ryan Sawhill 2016-04-06 22:29:35 UTC
Upstream docs (http://httpd.apache.org/docs/trunk/mod/mod_log_config.html#customlog) suggest this has already been added to trunk somehow despite status of that upstream bug.

Syntax: CustomLog file|pipe|provider format|nickname [env=[!]environment-variable| expr=expression]
    Modules implementing ErrorLog providers can also be used as a target for CustomLog messages. To use ErrorLog provider as a target, "provider:argument" syntax must be used. You can for example use mod_journald or mod_syslog as a provider:

    # CustomLog logging to journald
    CustomLog "journald" "%h %l %u %t \"%r\" %>s %b"

    # CustomLog logging to syslog with "user" facility
    CustomLog "syslog:user" "%h %l %u %t \"%r\" %>s %b"

I didn't look into the code behind it (or even checkout trunk and test), but man if it's something that gets stable and backported to upstream's 2.4, wow we *have* to backport it to RHEL's httpd24. It would make life so much easier for so many people.

Comment 7 Joe Orton 2016-04-07 07:50:03 UTC
Yes, Jan wrote mod_journald and pushed it upstream, which provides both access logging and error logging via journald.  See also bug 1168956.

The big problem with this is that there is a severe performance impact to logging via journald at the moment due to a kernel restriction.  We don't want to add this to RHEL httpd unless the journald/kernel side is also resolved.

Comment 8 Gerald Prock 2016-04-11 06:45:12 UTC
For us it would be really great if the second module "mod_syslog" would be provided in RHEL7 to log directly to rsyslog without the way over /usr/bin/logger and journald.

On high load server (>1000 req/s) the way over the default logger crash the logging (httpd -> logger -> journald -> rsyslog). With the module the direct way from httpd to rsyslog would be really nice.

At the moment we have to use a script instead of the logger to log directly to rsyslog. Thanks to Ryan to help us to improve the performance of that way.

Comment 9 Pat Riehecky 2016-04-11 14:07:05 UTC
This feature would be super useful on my end.

Could the enhanced logging be provided as a Tech Preview feature with known performance problems?  I've no real preference between syslog and journald, but I would very much like to see this in my production environment.

Comment 12 Pat Riehecky 2018-10-02 21:08:08 UTC
Just swinging back around on this one.

Comment 13 Joe Orton 2018-10-05 09:14:28 UTC
Sorry.  The patches are in trunk, I'll revive the effort to get them backported to 2.4.x and we can look at pulling them into RHEL7 httpd.

Comment 14 Pat Riehecky 2018-10-09 13:39:12 UTC
Awesome! Any chance they'll make it into RHEL8 too?

Comment 21 Pat Riehecky 2019-10-03 19:39:38 UTC
Just swinging back around...

Comment 26 Joe Orton 2020-06-15 10:50:33 UTC
It does not appear to be feasible to backport syslog support for CustomLog.  However, I have found a way to backport journald support, though without the structured logging support used in upstream 2.5's mod_journald.

I am therefore adjusting the RFE to cover just journald.  mod_journald will be supported once there is a stable (e.g. 2.6) release which we can package as a new module stream.

Comment 28 Joe Orton 2020-06-15 12:21:42 UTC
The syntax supported is:

  CustomLog journald:priority format|nickname

where "priority" is a priority string as in LogLevel http://httpd.apache.org/docs/2.4/mod/core.html#loglevel
Only priorities up to debug are permitted (the syslog/journald interfaces do not support trace* levels)

Comment 31 Branislav Náter 2020-06-15 14:56:55 UTC
(In reply to Joe Orton from comment #28)
> The syntax supported is:
>   CustomLog journald:priority format|nickname
> where "priority" is a priority string as in LogLevel
> http://httpd.apache.org/docs/2.4/mod/core.html#loglevel
> Only priorities up to debug are permitted (the syslog/journald interfaces do
> not support trace* levels)

Were there any documentation backported?

Comment 32 Joe Orton 2020-06-15 15:25:07 UTC
No; in fact overriding the priority level is not possible with the extensions to mod_log_config and mod_journald from trunk/2.5, which will always default to the INFO level for transfer logs (and maps error log levels to the appropriate level from httpd internal log level).

Not sure where best to document this, release notes is maybe sufficient?

Comment 42 errata-xmlrpc 2020-11-04 03:35:12 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: httpd:2.4 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.