Closed sunuslee closed 7 years ago
I'm pretty conservative about making changes to Squirrel.Mac, given:
So to consider this PR, I'll need a more thorough description of the bug and how this is addressing it.
@joshaber when this bug happened , if the user finished downloading the new update file, the app will quit and won't launch again. because it's ShipIt's responsibility to bring up the app, but ShipIt can not start running in the first place, because SMJobSumit failed.
but ShipIt can not start running in the first place, because SMJobSumit failed
But why does it fail?
@joshaber
i wish i knew the answer. but it seems like an apple's bug to me.
when you run
launchctl submit -l test -p /usr/bin/touch -- /usr/bin/touch /var/tmp/test
it should be a file in /var/tmp/test and it will show you this job
$ launchctl list test
{
"LimitLoadToSessionType" = "Aqua";
"Label" = "test";
"TimeOut" = 30;
"OnDemand" = false;
"LastExitStatus" = 0;
"Program" = "/usr/bin/touch";
"ProgramArguments" = (
"/usr/bin/touch";
"/var/tmp/test";
);
};
but when this bug happened, this simple command will only show you the job in launchctl list , and not executing at all. i wish i knew what's going on inside the system:(
@joshaber can you offer a better solution?
I can't since I don't fully understand the bug or how it happens. But I'm hesitant to fix an apparent race condition by introducing another potential race condition.
Closing due to inactivity.
SMJobSubmit will fail on some osx(tested in 10.11). when this happened, the job will be shown in the launchctl list but will never be executed (ShipIt not running) and the process will be terminated by later [NSApp terminate:self] as expected. so we manually launchctl start the ShipIt job.
Signed-off-by: sunuslee sunuslee@gmail.com