HP-UX 11i Version 2 Release Notes (October 2003)

Internet and Networking
IPv6 Support
Chapter 6
158
Any entries written to the /etc/utmpx file will not be updated in the daemon's database
in real time. As a result, commands like who might not show the information instantly
but will eventually show it after a time lag. This time lag could range from a few seconds
on lightly loaded systems to a few minutes on heavily loaded systems.
Entries written by legacy archive applications that update only the /etc/utmp file will
not be reflected in the new database and commands like who will no longer report such
entries. It is recommended that such applications re-compile for their entries to be
reflected in the new user-accounting database.
Applications that directly read entries from the wtmp and btmp files will have to be
modified to use the new bwtmps interfaces for accessing/updating the new wtmps and
btmps databases.
HP-UX commands that either access or modify the utmp/x, wtmp, and btmp files have
been modified to use the new interfaces and thus will be using new databases instead of
their old counterparts.
HP-UX commands read the new in-memory utmps database for information related to
active user sessions, and the commands access wtmps and btmps databases for other
accounting related records.
Compatibility
The old interfaces getut and getutx, which update the /etc/utmp and /etc/utmpx
files have not been modified. However, there will be a time lag in the entries written to
these files being reflected in the utmpd's database and vice versa. But this does not
break compatibility with any existing applications, as the legacy interfaces are
unmodified.
Performance
The solution improves performance in the following cases:
• When a large number of login sessions are opened simultaneously (a few thousand in
number) on the system and a huge number of processes are updating the
user-accounting database simultaneously.
In the earlier implementation, this situation would cause the system to enter a crawl
condition. Now, with the new solution, the system will go back to a normal state in a
few seconds.
• The solution also fares better with the user-accounting database containing a large
number of entries. The getutsid(), getutsline() APIs perform more than two
orders of magnitude better when compared to the old implementation with a user
accounting database containing around 20,000 records. The new APIs give better
results as the number of entries in the database increase.
The performance improvement is due to two factors:
• The linear searching of the /etc/utmp and /etc/utmpx files record-by-record to find
and update an entry being replaced by a near-constant time algorithm to query the
utmpd daemon's database.
• The updates to the /etc/utmp and /etc/utmpx files (disk read/writes) being
replaced by updates to the in-memory database maintained by the daemon.