ttscoff / Slogger

Social logging script for Day One
757 stars 160 forks source link

Slogger launchd fails when running after Wake #23

Open joshuakarjala opened 12 years ago

joshuakarjala commented 12 years ago

When I wake from sleep - the Slogger agent doesn't complete. In Console I can see this.

31/08/12 09.05.24,844 com.apple.launchd.peruser.501[230]: (com.brettterpstra.Slogger[48111]) Exited with code: 1

In runlog.txt I get:

[Fri Aug 31 09:05:24 2012] Slogger v2.0 (2.0.10.0) {:develop=>false, :quiet=>false, :onlyrun=>false, :config_file=>"/usr/local/slogger/slogger_config", :max_retries=>1, :timespan=>1, :undo=>false}

Running the agent manually with:

launchctl start com.brettterpstra.Slogger

works fine.

Any idea what could be up? Any way to get more detail on why it's crashing?

Setup: 2011 Macbook Air OSX 10.8.1

ttscoff commented 12 years ago

Not sure how launchd performs with sleep. I never sleep my main machine, so it may just be a case of tasks not running if they trigger during sleep. There might be a setting for that I may be missing. Otherwise you might need to find another way to schedule the task. Please let me know if you figure something out.

blackader commented 12 years ago

From here: http://forums.macrumors.com/showthread.php?t=1212798

StartCalendarInterval This optional key causes the job to be started every calendar interval as specified. Missing arguments> are considered to be wildcard. The semantics are much like crontab(5). Unlike cron which skips job invocations when the computer is asleep, launchd will start the job the next time the computer wakes up. If multiple intervals transpire before the computer is woken, those events will be coalesced into one event upon wake from sleep.

ttscoff commented 12 years ago

StartCalendarInterval is what is used in the launchd plist installed by install.rb. Do yours not have that?

joshuakarjala commented 12 years ago

Yeah I saw that definition. The plist does have this setting.

As stated it seems that launchd is actually trying to run the script when waking. But it is failing with Code 1.

blackader commented 12 years ago

I was merely confirming that the tasks indeed don't run when asleep, but rather when the machine wakes.

larryhynes commented 12 years ago

I was getting a similar error message, though I wasn't connecting it to Waking, more likely a system upgrade in my case. After a lot of poking about I found that /usr/bin/ruby, which is specified in the .plist file, was symlinked to /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby and was failing because Slogger needed the dependencies that were installed with /Users/larry/.rvm/bin/ruby.

I don't know if this is of any use in your case, hopefully it might help.

An easy way to test is to open a new terminal window and run $ /usr/bin/ruby /path/to/slogger/slogger. If that returns an error you can try running $ /path/to/your-up-to-date-ruby /path/to/slogger/slogger and see if that works. (It did in my case). Then you can edit the .plist file, replacing <string>/usr/bin/ruby</string> with <string>/path/to/your-up-to-date-ruby</string>.

I'm sure there are far more elegant ways to fix this, but it got me back up and running.

joshuakarjala commented 12 years ago

Thanks for the suggestion. But here it runs fine with /usr/bin/ruby

On 07/11/2012, at 05.02, larryhynes notifications@github.com wrote:

I was getting a similar error message, though I wasn't connecting it to Waking, more likely a system upgrade in my case. After a lot of poking about I found that /usr/bin/ruby, which is specified in the .plist file, was symlinked to /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby and was failing because Slogger needed the dependencies that were installed with /Users/larry/.rvm/bin/ruby.

I don't know if this is of any use in your case, hopefully it might help.

An easy way to test is to open a new terminal window and run $ /usr/bin/ruby /path/to/slogger/slogger. If that returns an error you can try running $ /path/to/your-up-to-date-ruby /path/to/slogger/slogger and see if that works. (It did in my case). Then you can edit the .plist file, replacing /usr/bin/ruby with /path/to/your-up-to-date-ruby.

I'm sure there are far more elegant ways to fix this, but it got me back up and running.

— Reply to this email directly or view it on GitHub.