Project

General

Profile

Actions
Copy link

Bug #1728

open

utmp_update: wrong number of args or invalid user

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

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2011-11-04
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

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
Copy link
 #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
Copy link
 #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.

syscall::rexit:entry
/execname=="utmp_update"/
{
    printf("utmp_update exited with code %d", arg0);
    @[arg0] = count();
}

tick-60sec
{
    printa(@);
}

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

Actions
Copy link
 #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
Copy link
 #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.

[1] http://pubs.opengroup.org/onlinepubs/007904875/functions/endutxent.html

Actions
Copy link
 #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.)

Actions
Copy link

Also available in: Atom PDF