On my machine (16.04.1) it seems that /dev/log is missing. It's probably always been missing.

The real reason I am here asking for help is that I am using virtualmin with csf and the SYSLOG_CHECK option has always failed (even when the OS was still 14.04 trusty).

This is what happens when I run logger:

# logger hi there
logger: socket /dev/log: No such file or directory

I also tried the 'python' way of doing things, as per this question:

# python -c 'import syslog; syslog.syslog("Hello World")'
(nothing is outputted, or appears in syslog)

So, looking at the /dev/ folder I notice that there is no 'log' there at all.

I checked on another machine (v14.04) and it has it: srw-rw-rw- 1 root root 0 Dec 16 20:34 log=

The main differences between the two machines are that the former was a launched instance from vultr.com (using an cloud-init aware install that they supplied), vs the latter machine (which works) which used an ubuntu ISO (a long time ago).

So, to the question: How do I go about fixing the issue of why I don't have a /dev/log file that some application (csf) is probably trying to write to? Note there are other messages appearing in /var/log/syslog, so it's all a little confusing to me.

Any help appreciated.


Contents of /lib/systemd/system/systemd-journald-dev-log.socket:

Description=Journal Socket (/dev/log)
Documentation=man:systemd-journald.service(8) man:journald.conf(5)



  • I'm facing the same issue in my Android 5 device. But in my device there is no /run/systemd/journal/syslog or /run/systemd/journal/dev-log /dev/log file present in my device. And in our code base, there is no "SysSock.Use" as well. Aug 8, 2022 at 7:53

4 Answers 4


Check if you have /run/systemd/journal/dev-log; it should be a socket:

$ ls -l /run/systemd/journal/dev-log
srw-rw-rw- 1 root root 0 Dec 16 09:17 /run/systemd/journal/dev-log

If this checks out, then you can simply make a symbolic link from /dev/log to /run/systemd/journal/dev-log:

sudo ln -s /run/systemd/journal/dev-log /dev/log
  • thanks, but this solution doesn't survive a reboot... any idea why? (It works fine up to that point). After reboot /dev/log is gone again
    – cmroanirgo
    Dec 16, 2016 at 18:36
  • 2
    It does not survive a reboot because /dev is a temporary filesystem. On my machines /dev/log is present and pointing to /run/systemd/journal/dev-log. It should be created automatically at startup by the socket service file /lib/systemd/system/systemd-journald-dev-log.socket.
    – AlexP
    Dec 16, 2016 at 18:43
  • Thanks, that file is there... and contains references to systemd-journald.service and the proper paths. If I run systemctl | grep systemd-journald I see that it's 'loaded active'...
    – cmroanirgo
    Dec 16, 2016 at 18:52
  • 1
    It should have a line saying Symlinks=/dev/log below ListenDatagram=/run/systemd/journal/dev-log.
    – AlexP
    Dec 16, 2016 at 18:53
  • yes, I update the Q to show the contents :)
    – cmroanirgo
    Dec 16, 2016 at 18:56

For me this ended up being a problem with how the imuxsock module used in rsyslog was working with systemd.

In the imuxsock documentation they walk through how the module is supposed to work for systemd. Step 1 was where I was seeing issues:

Step 1: Select name of system socket

  1. If the user has not explicitly chosen to set SysSock.Use="off" then the default listener socket (aka, “system log socket” or simply “system socket”) name is set to /dev/log. Otherwise, if the user has explicitly set SysSock.Use="off", then rsyslog will not listen on /dev/log OR any socket defined by the SysSock.Name parameter and the rest of this section does not apply.

  2. If the user has specified sysSock.Name="/path/to/custom/socket" (and not explicitly set SysSock.Use="off"), then the default listener socket name is overwritten with /path/to/custom/socket.

  3. Otherwise, if rsyslog is running under systemd AND /run/systemd/journal/syslog exists, (AND the user has not explicitly set SysSock.Use="off") then the default listener socket name is overwritten with /run/systemd/journal/syslog.

The system should have falling into Step 3 and changing the default path to be "/run/systemd/journal/syslog" but instead it was remaining "/var/log". This meant that the imuxsock module would try (and succeed sometimes) to create a socket at /dev/log where there should instead be symbolic link created by the systemd-journald-dev-log.socket. In the case that it would fail to create the real socket, the symbolic link would still be removed.

That documentation was the outcome of this issue reported on the rsyslog github. If you want to skip the discussion and jump straight to the changes see PR#1 and PR#2 respectively.

My solution was to just configure the imuxsock module to use the systemd path in my /etc/rsyslog.conf:


This seems to have fixed my issue and sounds like a good solution here since it would explain why the symbolic link might disappear again after you would manually create it.

If you look on your system and "/run/systemd/journal/syslog" is not present look at the "syslog.socket" to see if it is starting successfully as that is what is responsible for creating the socket.

systemctl status syslog.socket

It could be that your version of rsyslog.service doesn't define syslog.service as an alias which is needed as the syslog.socket tries to active that service.

For what it is worth I am running on an embedded version of Linux so it isn't a perfect replication of the problem here, but it seemed relevant enough to share.

  • I think this might be a race condition: If rsyslog starts before systemd-journald starts listening to /run/systemd/journal/syslog then rsyslog incorrect assumes the system isn't systemd and re-creates /dev/log as a socket.
    – docwhat
    Jul 13, 2020 at 18:44

Simple, restart systemd-journald.service and you should be fine

sudo systemctl restart systemd-journald.service


Are you sure that rsyslog is installed? In my case, I had to install rsyslog to resolve the issue in Ubuntu 16.04:

sudo apt-get install -y rsyslog

Note that even before I installed rsyslog, my /lib/systemd/system/systemd-journald-dev-log.socket contained the same content you show in your post.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .