1

On all my Unixes (CentOS, FreeBSD, MacOS X) I activate the system accounting as a basic security rule.

On MacOS X (Yosemite, 10.10.3) I see a misbehaviour I am investigating to fix.

Everytime I run lastcomm to analyze a recent set of processes terminated I find processes really terminated but with dates coming from the future as in this example:

••My_Mac••$ lastcomm | more
lastcomm   -X      bob      ttys007    0.00 secs Mon Jul 26 14:13 (0:00:03.05)
more       -       bob      ttys007    0.00 secs Mon Jul 26 14:13 (0:00:03.05)
stty       -       bob      ttys007    0.00 secs Mon Jul 26 14:13 (0:00:00.05)
path_helpe -       bob      ttys007    0.00 secs Mon Jul 26 14:13 (0:00:00.50)
sshd       -SF     _sshd    __         0.00 secs Mon Jan 27 17:31 (0:00:04.91)
procmail   -S      bob      __         0.00 secs Mon Jul 26 14:11 (0:00:00.09)
cron       -F      root     __         0.00 secs Mon Jun  1 13:10 (0:00:00.33)
sendmail   -S      root     __         0.00 secs Mon Jun  1 13:10 (0:00:00.31)
postdrop   -       root     __         0.00 secs Mon Jun  1 13:10 (0:00:00.09)
[...]
••My_Mac••$ date
Mon Jun  1 13:12:07 CEST 2015
••My_Mac••$

At first, the problem isn't as simple as a timezone error:

Jul 26, 14:13 (wrong timestamp) and Jun 1, 13:10 (correct timestamp) are many days appart.

This isn't either a huge time drift caused by a date erroneous use. Moreover this server is ntp synchronized on a strate 1 ntp server.


Did someone else see the same misbehaviour?
Do you see a path to better investigate this problem?
Is this a known bug?

  • Same behavior here (OS X 10.10.3 "Yosemite"): bash -F jaume ttys001 0.00 secs Mon Jul 26 21:37 (0:00:00.00) sudo -S root ttys001 0.00 secs Mon Jun 1 20:35 (0:00:00.02).It is interesting to note that times seem to be reported correctly if the user that owns the process is root. – jaume Jun 1 '15 at 18:54
2

Found same misbehavior on ElCapitan (MacOSX 10.11..). On investigation, saw that timestamp data in /var/account/acct file was correct. Compiling source of lastcomm.c in
http://opensource.apple.com/tarballs/shell_cmds/shell_cmds-187.tar.gz
showed compiler message "warning: incompatible pointer types passing 'u_int32_t *' (aka 'unsigned int *') to parameter of type 'const time_t *' (aka 'const long *')"

The following patch to fix bad accounting timestamp worked for me in ElCapitan. It may work for Yosemite (10.10..) and earlier.

*** lastcomm.c  2016/08/26 19:44:23 1.1
--- lastcomm.c  2016/08/27 00:30:49 1.2
***************
*** 135,138 ****
--- 135,140 ----
        if (!*argv || requested(argv, &ab)) {

+           time_t timelong;
+           timelong = ab.ac_btime;
            t = expand(ab.ac_utime) + expand(ab.ac_stime);
            (void)printf(
***************
*** 144,148 ****
                 user_from_uid(ab.ac_uid, 0), UT_LINESIZE,
                 UT_LINESIZE, getdev(ab.ac_tty),
!                t / (double)AHZ, ctime(&ab.ac_btime));
            delta = expand(ab.ac_etime) / (double)AHZ;
            printf(" (%1.0f:%02.0f:%05.2f)\n",
--- 146,150 ----
                 user_from_uid(ab.ac_uid, 0), UT_LINESIZE,
                 UT_LINESIZE, getdev(ab.ac_tty),
!                t / (double)AHZ, ctime(&timelong));
            delta = expand(ab.ac_etime) / (double)AHZ;
            printf(" (%1.0f:%02.0f:%05.2f)\n",
  • I don't have a Mac to test it but that could be a valid answer. You should remove the other one or integrate it to this one. – Julie Pelletier Aug 27 '16 at 1:00
  • Patch correct. Tested on Yosemite 10.10.5: OK. I advise you to provide it to Apple. – dan Aug 28 '16 at 23:07
  • 1
    Apple Bug Reporter entry submitted with number 28056519 – Mike142Wood Aug 29 '16 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.