sar under OS X 10.4.3

what a weird hack! OS X comes with the sar command, which I found to be very helpful to look at what a machine is doing.
Just running

Will look for todays performance. You have to collect it first. Traditionally this gets done via a cron job. OS X really likes to use launchd instead. But I need to get some work done, I don’t have the time to learn another propriatary solution for a very common problem: Running things periodically. So I stick with cron. Not sure why it is running on some of the systems and not on others. If you follow this make sure cron shows up in a ps ax | grep cron command. If it does then you could enable daily performance traces reportable by “sar” by adding

# run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib/sa/sa1 1 1
# generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib/sa/sa2 -A

to /etc/crontab. If cron runs then it will reread the file automatically. The remaining problem for me and under
OS X 10.4.3 was that sa1 overwrote instead of appended the performance data. A really terrible hack that fixed this was to change the lines in /usr/lib/sa/sa1 from

exec ${ENDIR}/sadc 1 1 ${DFILE}


exec ${ENDIR}/sadc 1 1 >>${DFILE}

This works, but generates error messages like:

sar: drivepath sync code error -4

when I retrieve the daily performance data.

This is good enough for me. All I am after is to find out what that 30TB Xsan has been doing.

5 Responses to “sar under OS X 10.4.3”

  1. Bas Swildens Says:

    Hi Andreas, encountered same sar issues as you did. Was driving me mad :) Created an alternative for starting sar cycle to get rid of the error message… See here:

    Cheers, Bas

  2. Juergen Says:

    Hi there,

    I know it’s late… But I have the same problem with sar on OS X 10.9
    The site is down. Do you have the “alternative” for starting sar?

    [576][jb@jbmpb: /var/log/sa]$ sar -u

    12:14:45 %usr %nice %sys %idle
    12:19:45 4 0 1 95
    sar: drivepath sync code error -3
    sar: drivepath sync code error -3
    sar: drivepath sync code error -3
    12:24:45 4 0 1 95
    12:29:45 4 0 2 93

    Thanks in advance


  3. SeaBash Says:

    If you’re not looking to have sar run automatically, e.g. via CRON, launchd, etc, you can simply run sar “on-demand” like this (don’t type #comment lines)…

    # The -u (cpu) switch is default, so it shows cpu stats 3x at 1 second intervals…
    sar 1 3

    # Refer to sar manpage and try things like…
    # Network options…
    sar -n DEV 1 3

    I found usage tips from this site…

  4. Jay Pike Says:

    Spent 40 hours trying to figure another way around this whole issue. Its definitely a bug (in my opinion) with Apple’s implementation of sar. ’sadc’ should not default to ‘truncate’ and should ‘append’ instead.

    I tried building sysstat and was successful in building it, but it relies on /proc/stat, which is a Linux proprietary function. There was a /proc workaround for Mac that was done in Python, but, I didn’t want to try that (too much of a bandaid).

    Your solution, Andreas, is the best solution and only solution I can seem to find.

    I got frustrated by the errors, so, I created an alias that helps remove these. You can add this to your .aliai file for csh/tcsh:

    alias sar “/bin/sh -c ’sar \!* 2>&1|grep -v drivepath’”

    I’m using ‘tcsh’, but for bash, this would work in your .bashrc:

    sar() { /bin/sh -c “sar $* 2>&1|grep -v drivepath”; }

    I hope this helps someone as it did me!

    Jay Pike

  5. Jay Pike Says:

    A couple of additional comments for those that may find this blog:

    1) ‘cron’ is the best and easiest way to run this. The ‘cron’ daemon runs automatically after the first time you type ‘crontab -e’ as the ‘root’ user and add something similar to what is below:

    # run system activity accounting tool every 10 minutes
    */10 * * * * /usr/lib/sa/sa1 1 1
    # generate a daily summary of process accounting at 23:53
    53 23 * * * /usr/lib/sa/sa2 -A

    2) The /usr/lib/sa/sa1 script now looks like this:

    if [ $# = 0 ]
    exec ${ENDIR}/sadc 1 1 ${DFILE}
    exec ${ENDIR}/sadc $* ${DFILE}

    In order to make this work, doing the original adjustment from above with the listed crontab entries will not work since the statement listed in the ‘else’ will be executed. To resolve this, add the ‘>>’ into both lines, like this:

    if [ $# = 0 ]
    exec ${ENDIR}/sadc 1 1 >> ${DFILE}
    exec ${ENDIR}/sadc $* >> ${DFILE}

    Jay Pike

Leave a Reply

You must be logged in to post a comment.