24

/dev/log is the default entry for system logging. In the case of a systemd implementation (this case) it's a symlink to whatever /run/systemd/journal/dev-log. It used to be a receiving end of a unix socket handled by syslog daemon.

~$ echo "hello" > /dev/log 
bash: /dev/log: No such device or address
~$ fuser /dev/log
~$ ls -la /dev/log 
lrwxrwxrwx 1 root root 28 Aug 23 07:13 /dev/log -> /run/systemd/journal/dev-log

What is the clarification of the error that pops when you try to write to it and why isn't there a process holding that file (output from fuser /dev/log empty?

The logging does work normally on the system.

~$ logger test
~$ journalctl --since=-1m
-- Logs begin at Thu 2018-05-24 04:23:46 CEST, end at Thu 2018-08-23 13:07:25 CEST. --
Aug 23 13:07:24 alan-N551JM alan[12962]: test

Extending with comment suggestions

~$ sudo fuser /dev/log 
/run/systemd/journal/dev-log:     1   311
~$ ls -lL /dev/log
srw-rw-rw- 1 root root 0 Aug 23 07:13 /dev/log
10
  • @RuiFRibeiro Updated to make it clearer that the examples are from a systemd implementation. Commented Aug 23, 2018 at 10:58
  • what happens when you run logger "test"? Please add to the question. Commented Aug 23, 2018 at 10:59
  • 1
    Please, add to your question the output of sudo fuser /dev/log and ls -lL /dev/log
    – andcoz
    Commented Aug 23, 2018 at 11:51
  • @andcoz Bravo, the fuser was a permission issue. Would of have totally missed that due to the silence. Commented Aug 23, 2018 at 12:02
  • Related: How can I communicate with a Unix domain socket via the shell. You need to use something that uses connect rather than open. Commented Aug 23, 2018 at 19:22

3 Answers 3

17

I am summarizing the comments to a complete answer. Note that @MarkPlotnick was the first to point toward the right solution.

As you can see in ls -lL output, the file pointed by you link is a socket, not a regular file or a pipe.

~$ ls -lL /dev/log
srw-rw-rw- 1 root root 0 Aug 23 07:13 /dev/log

Look at the first character of the output. That s means that the file is a socket.

You cannot use the redirection mechanism > of bash (or, AFAIK, any other shell) to write in a socket because the shell will try to open the file and open does not support sockets. See man open for details.

You have to use a program that connects to a socket. See man connect for details.

As an example, you can use netcat or socat (see How can I communicate with a Unix domain socket via the shell on Debian Squeeze?).

For the sake of completeness, you can use the redirection on pipes.

~$ mkfifo /tmp/fifo
~$ ls -l /tmp/fifo
prw-rw-rw- 1 root root 0 27 ago 15.04 /tmp/fifo
~$ echo "hello" > /tmp/fifo

Look at the first character of the ls output. That p means that the file is a pipe.

1
  • 1
    Please also extend with your answer on why no processes were detected having a handle on the socked. Commented Aug 28, 2018 at 10:24
15

To add some additional info to the accepted (correct) answer, you can see the extent to which /dev/log is simply a UNIX socket by writing to it as such:

lmassa@lmassa-dev:~$ echo 'This is a test!!' | nc -u -U /dev/log 
lmassa@lmassa-dev:~$ sudo tail -1 /var/log/messages
Sep  5 16:50:33 lmassa-dev journal: This is a test!!

On my system, you can see that the journald process is listening to this socket:

lmassa@lmassa-dev:~$ sudo lsof | grep '/dev/log'
systemd       1                 root   29u     unix 0xffff89cdf7dd3740       0t0       1445 /dev/log
systemd-j   564                 root    5u     unix 0xffff89cdf7dd3740       0t0       1445 /dev/log

It got my message and did its thing with it: (i.e. appending to the /var/log/messages file).

Note that because the syslog protocol that journald is speaking expects datagrams (think UDP), not streams (think TCP), if you simply try writing into the socket directly with nc you'll see an error in the syscall (and no log show up).

Compare:

lmassa@lmassa-dev:~$ echo 'This is a test!!' | strace nc -u -U /dev/log 2>&1 | grep connect -B10 | egrep '^(socket|connect)'
socket(AF_UNIX, SOCK_DGRAM, 0)          = 4
connect(4, {sa_family=AF_UNIX, sun_path="/dev/log"}, 10) = 0

lmassa@lmassa-dev:~$ echo 'This is a test!!' | strace nc  -U /dev/log 2>&1 | grep connect -B10 | egrep '^(socket|connect)'
socket(AF_UNIX, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_UNIX, sun_path="/dev/log"}, 10) = -1 EPROTOTYPE (Protocol wrong type for socket)

Note I elided some syscalls for clarity. The important point here is that the first call specified the SOCK_DGRAM, which is what the /dev/log socket expects (since this is how the socket /dev/log was created originally), whereas the second did not so we got an error.

-2

You should verify /run/systemd/journal/dev-log, its permissions and who's using it. You were checking a link.

7
  • That doesn't influence the results in any way. I mention it as being a link also in the question. Commented Aug 23, 2018 at 10:49
  • That's strange. It would be interesting to know your distro. On CentOS 7, /dev/log is a socket, used by the /usr/lib/systemd/systemd-journald process. Commented Aug 23, 2018 at 11:08
  • I find it hard to believe that "fuser /run/systemd/journal/dev-log" would show nothing. Commented Aug 23, 2018 at 11:16
  • 1
    This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
    – Jeff Schaller
    Commented Aug 23, 2018 at 12:17
  • @JeffSchaller Better have a look at the edited question. You'll find I did provide the answer. Commented Aug 23, 2018 at 13:10

You must log in to answer this question.

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