(Incorrect?) size of utmp records

[sixhills]

I've noticed that the latest 64-bit Raspberry Pi OS writes utmp records (to /var/run/utmp and /var/log/wtmp) of 400 bytes and I'm wondering whether this is intentional or a build error.

On almost all modern Linux systems, utmp records are 384 bytes in length. The extra 16 bytes are accounted for by the size of the ut_session, ut_tv.tv_sec and ut_tv.tv_usec fields. utmp.h says that these fields should each be 32 bits and they are 32 bits on almost all systems, regardless of whether the system is 32-bit or 64-bit. On Raspberry Pi OS 64-bit, these fields are all 64 bits.

utmp.h states that "The ut_session and ut_tv fields must be the same size when compiled 32- and 64-bit. This allows data files and shared memory to be shared between 32- and 64-bit applications."

I've found one other system where utmp records are 400 bytes and that's Ubuntu 20.10 64-bit aarch64 for Raspberry Pi. But Ubuntu 20.10 64-bit x86_64 implements the normal 384-byte records.

So is the use of 64-bit fields in these three utmp fields a bug or a feature?

[sixhills]

The fundamental cause is that __WORDSIZE_TIME64_COMPAT32 isn't set in aarch64 (https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d8c7d79c4c95c72c1b/sysdeps/aarch64/bits/wordsize.h#L28), so I guess the question reduces to whether that's intentional.

[lurch]

Ubuntu 20.10 64-bit aarch64 for Raspberry Pi

That implies this is probably a Debian aarch64 "thing" rather than a 64-bit Raspberry Pi OS "thing"? 🤷 (both Raspberry Pi OS and Ubuntu are built on top of Debian)

On my 64-bit Ubuntu 18.04 laptop (on which I'm currently writing this reply), man utmp says:

           struct utmp {
               short   ut_type;              /* Type of record */
               pid_t   ut_pid;               /* PID of login process */
               char    ut_line[UT_LINESIZE]; /* Device name of tty - "/dev/" */
               char    ut_id[4];             /* Terminal name suffix,
                                                or inittab(5) ID */
               char    ut_user[UT_NAMESIZE]; /* Username */
               char    ut_host[UT_HOSTSIZE]; /* Hostname for remote login, or
                                                kernel version for run-level
                                                messages */
               struct  exit_status ut_exit;  /* Exit status of a process
                                                marked as DEAD_PROCESS; not
                                                used by Linux init (1 */
               /* The ut_session and ut_tv fields must be the same size when
                  compiled 32- and 64-bit.  This allows data files and shared
                  memory to be shared between 32- and 64-bit applications. */
           #if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32
               int32_t ut_session;           /* Session ID (getsid(2)),
                                                used for windowing */
               struct {
                   int32_t tv_sec;           /* Seconds */
                   int32_t tv_usec;          /* Microseconds */
               } ut_tv;                      /* Time entry was made */
           #else
                long   ut_session;           /* Session ID */
                struct timeval ut_tv;        /* Time entry was made */
           #endif

               int32_t ut_addr_v6[4];        /* Internet address of remote
                                                host; IPv4 address uses
                                                just ut_addr_v6[0] */
               char __unused[20];            /* Reserved for future use */
           };

ping @waveform80 in case he has any "Ubuntu 64-bit aarch64 for Raspberry Pi" knowledge he'd like to share 😉

[sixhills]

Thanks for the response. It looks like a glibc aarch64 "thing", so further up the tree than Debian. I'll live with it and write separate code for aarch64. It's odd, though, that the comment about "must be the same size when compiled 32- and 64-bit" is still present in aarch64 glibc, although ignored in the code.

[lurch]

When dealing with large, old codebases, it's not uncommon to find mismatches between comments/documentation and what the code is actually doing 😉 I'm sure the glibc maintainers would appreciate a patch (or even just a bug report).