Bug #1728


utmp_update: wrong number of args or invalid user

Added by Josef Sipek over 11 years ago. Updated almost 10 years ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


Every so often, I find these in dmesg output...

Nov  3 22:46:03 meili utmp_update[1613]: [ID 845426 user.error] Wrong number of arguments or invalid user 
Nov  3 22:46:03 meili utmp_update[1614]: [ID 845426 user.error] Wrong number of arguments or invalid user 

Everything seems to be working correctly.

Actions #1

Updated by Rich Lowe over 11 years ago

  • Tags deleted (needs-triage)

It's likely going to be hard to track this down without catching it in the act.

The stand-out reason for this, is that utmp_update's error reporting is terrible it uses a single message for every error, and varies the exit code. Horrific.

I would suggest either:

  1. Fixing it to log useful errors, using them to discover what's wrong.
  2. A DTrace script which watches for non-0 exits of utmp_update, and records the status (which at least would narrow it down a little bit).

#1 should be done at some point regardless.

Actions #2

Updated by Josef Sipek over 11 years ago

Rich suggested using DTrace to get more information about what's going on. I ran the following in one terminal, while using the system as always.

    printf("utmp_update exited with code %d", arg0);
    @[arg0] = count();


It turns out that anytime I close a terminal, utmp_update returns 7.

Actions #3

Updated by Rich Lowe over 11 years ago

It appears likely that rxvt-unicode is doing something wrong here, though this bug should stay open to record the fact that utmp_update is a massive pile.

Actions #4

Updated by Josef Sipek over 11 years ago

So, I've poked around urxvt and read the pututxline code in illumos. According to the standard [1], urxvt doesn't actually do anything wrong. It does not fill in the ut_user field, which works fine if you run urxvt as root. If you are not root, the helper process utmp_update blows up because it didn't get a user name and the error propagates back to pututxline which happily returns NULL. Keep in mind that this is during the termination of uxrvt, when it tries to put a DEAD_PROCESS utx entry.

In other words, it really looks like utmp_update bug.


Actions #5

Updated by Josef Sipek almost 10 years ago

Alright, after procrastinating a bit I looked into this some more. Here's what happens when an unprivileged application calls pututxline...

1) pututxline notices that the user isn't root, and so it forks & exec's utmp_update
2) utmp_update mangles the arguments and then calls pututxline
3) pututxline updates /etc/utmpx (which is a symlink to /var/adm/utmpx)
4) pututxline then sends a message over a named pipe (/var/run/utmppipe) to utmpd (a smf managed service)
5) utmpd keeps an eye out on the original process to ensure that the process removes itself from utmpx

I am considering replacing utmp_update binary with just libc sending the utmpx update to utmpd directly. (Either via the existing pipe or via a door call.)


Also available in: Atom PDF