syslog tag not properly included when writing to unix socket

Bug #1329400 reported by Simao
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description

When using `unix:/dev/log` to write to a socket, like so:

access_log syslog:server=unix:/dev/log,tag=nginx warn;

The tag is not used properly by syslog to write the log message. This causes the following message to be sent to syslog:

2014-06-12T15:02:09+00:00 user.notice wheezy wheezy nginx: - - localhost:8000 GET 503 206 | - unicorn=- total=0.00
0 | "curl/7.26.0" "/" "-"

wheezy is my hostname, and it's written in syslog's tag field. The tag nginx is there, but it's written in the beggining of the `msg` field.

My hostname is also written to syslog's `app-name` field.

The same faulty behaviour is observed with `error_log`.

This works properly when using a remote server, server=<ip>.

Simao (simaomm)
information type: Public → Public Security
information type: Public Security → Private Security
information type: Private Security → Private
information type: Private → Public
Revision history for this message
Thomas Ward (teward) wrote :

Which version(s) of Ubuntu does this happen on? What version of Ubuntu are you using? Are you using a PPA?

Changed in nginx:
status: New → Incomplete
Revision history for this message
Erico Fusco (ericopfusco) wrote :

I got the same bug.

Although I'm using a compiled version of nginx, that might help fix the issue on future releases. I'm using Ubuntu 14.04.1 LTS

nginx sends the package as described in the RFC 3164.


What happens is the unix rsyslog module generates a new HEADER no matter what the message it gets and removes the timestamp from the header that was sent by the socket client but it doesn't remove the hostname.

So basically what happens is:

Rsyslog adds a new header in the beggining: TIMESTAMP1 HOSTNAME1 TIMESTAMP2 HOSTNAME2 MSG
Then removes the timestamp that was sent by the socket client: TIMESTAMP1 HOSTNAME1 HOSTNAME2 MSG

I'm using nginx 1.7.7. The current version on Ubuntu (1.4.6) doesn't even have syslog support.

Since I'm using a compiled version and only using unix socket (because nginx 1.7.7 doesn't support syslog with TCP) I applied a patch that removes the hostname from nginx syslog message.

Revision history for this message
Simao (simaomm) wrote :

I am using also a compiled version of 1.7.7, I switched to UDP/TCP logging to make this work.

Revision history for this message
Jacob Magnusson (q-d-k) wrote :

Is there any way to change the tag while still sending to /dev/log?

Revision history for this message
Mihaly Arva-Toth (mihaly-arva-toth+ulaunchpad) wrote :

We are using nginx-1.8.0-1 from official nginx repository:

deb trusty nginx

We can confirm this issue, which affects nginx configured unix socket syslog. Please fix it.

Changed in nginx:
status: Incomplete → Confirmed
Revision history for this message
Thomas Ward (teward) wrote :


I'll leave this confirmed, but **this project does not track the repository.** Bugs in there go onto NGINX Trac -

Revision history for this message
Thomas Ward (teward) wrote :

All: Please refer to To quote the ticket:

Closing as a duplicate of
See details there.
With syslog-ng, just add flags(expect-hostname) to the corresponding source:
expect-hostname: If the expect-hostname flag is enabled, syslog-ng OSE will assume that the log message contains a hostname and parse the message accordingly. This is the default behavior for TCP sources. Note that pipe sources use the no-hostname flag by default.


This is listed upstream as "Not a Bug" and is instead mentioned that you should refer to rsyslog configuration. As a result of Upstream marking this 'not a bug' and closing the dupe ticket as 'works for me', I am closing this ticket. (The exact wording of this ticket was marked as a duplicate, and then that duplicate was closed).

Changed in nginx:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.