"invalid argument" error from logger command when passing messages via STDIN

Bug #1991436 reported by Ansgar Wiechers
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
util-linux (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Steps to reproduce:

apt-get install lxd-installer
lxd init
lxc launch ubuntu:jammy ct0
lxc exec ct0 -- bash

Then within the container run

echo foo | logger --id="$$"

Note: the command may work the first time, but subsequent invocations then produced the error described in my bug report.

(original report follows)
-----

When invoking the `logger` command on Ubuntu Jammy (bsdutils 2.37.2) with explicit PID and passing messages via STDIN

```
echo "some message" | logger -p local0.info --id="$$"
```

the command produces the following error instead of sending the message to syslog:

> logger: send message failed: Invalid argument

The error does not appear when the message is passed as an argument:

```
logger -p local0.info --id="$$" "some message" # this works!
```

When using process substitution the error only appears for the first log message:

```
exec > >(logger -p local0.info --id="$$")
echo "first message" # throws error, message not logged
echo "second message" # no error, message logged correctly
```

The issue does not exist in older versions (e.g. Ubuntu Xenial, bsdutils 2.27.1).

Workaround: Omit `--id` and include the PID in a tag.

```
echo "some message" | logger -p local0.info -t "foo[$$]"
```

Expected Behavior
-----------------

All messages passed via STDIN should be sent to syslog without throwing an error.

OS Release
----------

Description: Ubuntu 22.04 LTS
Release: 22.04

Package Version
---------------

bsdutils:
  Installed: 2.37.2-4ubuntu3
  Candidate: 2.37.2-4ubuntu3

Tags: jammy
description: updated
Revision history for this message
Steve Langasek (vorlon) wrote :

I cannot reproduce this on jammy.

$ echo "some message" | logger -p auth.info --id="$$"
$ echo $?
0
$

(using auth.info instead of local0.info because I have the former logged to a log file and the latter not).

Changed in util-linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Ansgar Wiechers (awiechers) wrote (last edit ):

Further investigation showed that the issue seems to occur only inside LXD containers, not in regular VMs. Sorry, I'm so used to working in containers these days that I didn't even think to check a VM as well.

Steps to reproduce:

apt-get install lxd-installer
lxd init
lxc launch ubuntu:jammy ct0
lxc exec ct0 -- bash

Then within the container run

echo foo | logger --id="$$"

Note: the command may work the first time, but subsequent invocations then produced the error described in my bug report.

Another detail is that the error does not seem to occur when --id is used without an argument:

root@ct0:~# echo "foo" | logger --id
root@ct0:~# echo "foo" | logger --id="$$"
logger: send message failed: Invalid argument

The exit status is 0 either way, so my scripts don't terminate because of this error. However, messages not being logged when they should be is still a problem, as is spurious error messages in (frequently running) cron jobs, which then flood my inbox.

Dan Bungert (dbungert)
Changed in util-linux (Ubuntu):
status: Incomplete → Triaged
importance: Undecided → Medium
description: updated
Revision history for this message
xhienne (xhienne) wrote :

I'm pretty sure this bug is caused by this issue: https://github.com/util-linux/util-linux/issues/2336

TLDR: when using the --id=NNN parameter, logger sends random UID and GID along with the PID you specify on the command line.

Those UID/GID probably don't exist on your machine/container and you are probably using some LSM module (like AppArmor, SELinux, etc) that checks the validity of the credentials sent through the sendmsg() syscall and thus denies the call with EINVAL.

You might want to test the patch I posted on github.

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.