Giters

rfmoz / tuptime

Report historical and statistical real time of the system, keeping it between restarts. Like uptime command but with more interesting output.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

OSX incorrect logging

Toby-Broom opened this issue · comments

commented

Hello,
Thanks for the tool, I wouldn't have an idea how to collect all this information.

I'm running it without issues on Ubuntu. However on OSX it's not possible as you can't create a crontab as root on OSX it seems as I tried to do it for another reason. It has to be done in a different way see here:

https://ampedup.wordpress.com/2017/09/12/crontab-not-working-in-macos-sierra/

commented

Could also be related to the other issue in that mac has Python 2.7 by default so I need to add /usr/local/bin to scripts that call it via cron so I can use the v3 Python

commented

Hello Toby,

You are welcome. Currently there are various issues with OSX and the way that Tuptime works, that makes the support hard to implement right.

  • The default path for the executable is /usr/bin/tuptime. For put any file there, it's mandatory to disable System Integrity Protection (SIP).

  • The execution at startup must be managed by LaunchD, it can be done, need a bit of work and testing, but fine.

  • The execution at shutdown it's an other story, right now, it's unavailable to do a proper implementation without ugly hacks. Tuptime not remains after execution and LaunchD expect it to be running before shutdown, because it pass the SIGTERM to all the daemons that was started, one of their requirements is "Provide a handler to catch the SIGTERM signal."[0] and Tuptime don't have it.

    There is a project called "macosx-script-boot-shutdown"[1] that wrap over the service and keep it started with:

    tail -f /dev/null &
    wait $!
    ...waiting with this hack until the SIGTERM call arrive. It is a clever workaround but I don't really like because it's not a clean solution, it is quite far from its equivalent in other OS.

    This is the main problem. I expect a better way, as they deprecated rc.shutdown, maybe the will provide a good alternative in a future.

  • The scheduled execution can't be done by cron, they deprecated it. There is a LaunchD alternative, it can be done, but like all, it requires doing and testing it.

Apart of all of these issues, the good thing is that OSX comes with Python3 and their internals still keeps the heritage from FreeBSD, whichs makes the key for running Tuptime.

Knowing that, as resume:

  • One alternative is to use it on OSX in conjuntion with "macosx-script-boot-shutdown".
  • An other alternative is to create only a LaunchD file for startup execution and an other for the scheduled execution, each minute. In that case, all the shutdown registers will be BAD and the accuracy will be <60 secs.
  • In any case, the LaunchD file for the scheduled execution must be created.

About your other issue with python3, you can change in the shebang line the Python version from 3 to 2.7 and it will run ok, at least for now.

Regards,

[0] - https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html
[1] - https://github.com/freedev/macosx-script-boot-shutdown

commented

Hello,

Is usr/local/bin a better path overall? this is not SIP protected and also supported on other platforms?

I agree the hack method isn't great I would use LaunchD, accept the 60sec errors, when apple creates the new methods then implement

I can try to create and test the plist files, could you point to the relevant commands required?

commented

Hello,

Yes, I suppose that it is possible to use /usr/local/bin instead or /usr/bin, it is easy to implement.

The key commands that tuptime needs are:

  • At startupt "tuptime -x"
  • At shutdow "tuptime -xg"
  • At schedule exectuion "tuptime -x"

That's all.

Please, let me know if you get this working on OSX.

Thanks,

commented

Sorry for the delay. I did the launchd for the schedule execution, so will have the 60sec errors. I assume I don't really need the startup one if I run the other every 60sec?

com.zerowidth.launched.tuptime.zip

I had some issue with python3 on 10.14 so needed the extra environment variables

commented

Hi Toby,

It is highly recommended to have the execution at startup. Suppose that you start the system and reboot it asap, it this case, probably you lost a register because it was done before 60 seconds.

Note that without a proper execution at shutdown, the issue is with the state of it. The init script execute '-xg' to register a gracefully shutdown, the launchd always register a bad one '-x'. Apart that the shutdown time isn't accurate.

At this point, if you only are going to use the scheduled execution, change the Tuptime argument from '-x' to '-xg' and pass over the shutdown state, that will always be OK.

Thanks for the file, indeed, it's the best approach that I have for runnin it in OSX. I will include it in the project.

About the issues with Python 3, with Tuptime 3.4.0 you can still change the shebang line to '#!/usr/bin/env python2.7' and use it normal.

Regards,

commented

Hi rfrail, I saw all my shutdowns are marked as bad. Since there is not a shutdown script option for OSX without the complex workarounds that you discussed before I feel this is a good compromise.

There could be a run once on boot second task with the -xg? This would mark all boots as good and fix the rapid restart issue? then the only defect on OSX is the missing 60sec on shutdown?

It was fine with python3 on 10.13 but a bug in python with localization showed up on 10.14 so I have to force the en_US with the environment variables. oops I thought you meant the shebang in another script not your script. I guess it would be better to use 2.7 in OSX as it's native to the OS, but since you said 3 was pre requisite I installed it anyway.

commented

Hi Toby,

Here are the answers:

;There could be a run once on boot second task with the -xg?

If you don't have any execution at shudown, don't trust in the shutdown state and mark all as 'OK' with -xg. You don't need a second task, you only have the scheduled execution, chage it there.

;This would mark all boots as good and fix the rapid restart issue?

This will fix the upcoming shutdowns, the old ones are already registered on the db (but you can chage it with sqlite if you want).

;then the only defect on OSX is the missing 60sec on shutdown?

Using only the scheduled execution with '-xg' you will have:

  • Accuracity under 60 seconds on shutdown.
  • Unreliable shutdown state, it allways be OK.

;I thought you meant the shebang in another script not your script. I guess it would be better to use 2.7 in OSX as it's native to the OS, but since you said 3 was pre requisite I installed it anyway.

I mean to the Tuptime execution file, please, open it a see the shebang line, you can chage it to 2.7, up today, it works fine, but I recommend version 3 because 2.7 is in death way.

Please, let me know if you have any other question.