4 ms·

> “it just works” level which OS X I have experienced issues with launchd which do not exist in the components that it replaced (e.g. cron, init, etc). For ex

by pyre 12y ago

> “it just works” level which OS X I have experienced issues with launchd which do not exist in the components that it replaced (e.g. cron, init, etc). For example, try setting a cronjob that runs every minute in launchd (e.g. running fetchmail). launchd says, "process exited too quickly" and disables the entry. [I'll note that this was an old example. Hopefully it's been fixed, but it's been far from "just works".]

acdha 12y ago
I was talking about the normal user experience which systemd is designed to handle – e.g. hotplug a USB camera and Chrome can use it for WebRTC. In this specific case, launchd is designed as an init replacement which keeps processes running. The restart throttle is designed to prevent crash loops which are horrible for battery life and tends to fill up logfiles, so it expects the process to run for at least 10 seconds. The easiest way to solve that would be to use it as intended and run fetchmail -d rather than spending the extra overhead restarting fetchmail all of the time.
- edwintorok 12y ago
  Why can't it look at the exitcode? If you exited with success why does matter how long it runs? The faster it is done with running processes the faster it can go back to sleep.
  - acdha 12y ago
    Think about it from the perspective of the operating system vendor: J. Random Codeslinger never checks return codes and always exits 0 so launchd ends up running the thing semi-constantly until syslog fills up the disk with "Usage: …" messages. If you have a professional sysadmin monitoring things, this gets fixed. If you're the average Mac user, you tell all of your friends that the last OS X release sucks and made your Mac slow and eventually go to the Apple store when your hard drive fills up.
    - pyre 12y ago
      What if the system process that you want to run periodically takes less than 60 seconds to run? Why should I have to wrap it in a shell script that ends with 'sleep 60' just to accommodate Apple?
- pyre 12y ago
  > The easiest way to solve that would be to use it as intended and run fetchmail -d rather than spending the extra overhead restarting fetchmail all of the time. fetchmail is also intended to run as a system daemon as part of a full-fledged mail system. This isn't always the case. Also, launchd not just initd, but crond per Apple's consolidation of system daemons. That is a use-case for crond. If Apple wants to replace crond, then they should make sure that the replacement works. I'm sure that I could find other programs that might exit in under 60 seconds that don't have a daemon mode[1]. [1] To be clear it wasn't the 'run every minute' that was causing issues, but the 'exits less than 60 seconds after it starts' that was tripping it up. I could run fetchmail every 10 minutes, but when it is able to connect/verify that there isn't new mail in under 60 seconds, then the whole process gets disabled. Oops!

by pyre 12y ago

acdha 12y ago

I was talking about the normal user experience which systemd is designed to handle – e.g. hotplug a USB camera and Chrome can use it for WebRTC. In this specific case, launchd is designed as an init replacement which keeps processes running. The restart throttle is designed to prevent crash loops which are horrible for battery life and tends to fill up logfiles, so it expects the process to run for at least 10 seconds. The easiest way to solve that would be to use it as intended and run fetchmail -d rather than spending the extra overhead restarting fetchmail all of the time.

edwintorok 12y ago
Why can't it look at the exitcode? If you exited with success why does matter how long it runs? The faster it is done with running processes the faster it can go back to sleep.
- acdha 12y ago
  Think about it from the perspective of the operating system vendor: J. Random Codeslinger never checks return codes and always exits 0 so launchd ends up running the thing semi-constantly until syslog fills up the disk with "Usage: …" messages. If you have a professional sysadmin monitoring things, this gets fixed. If you're the average Mac user, you tell all of your friends that the last OS X release sucks and made your Mac slow and eventually go to the Apple store when your hard drive fills up.
  - pyre 12y ago
    What if the system process that you want to run periodically takes less than 60 seconds to run? Why should I have to wrap it in a shell script that ends with 'sleep 60' just to accommodate Apple?
pyre 12y ago
> The easiest way to solve that would be to use it as intended and run fetchmail -d rather than spending the extra overhead restarting fetchmail all of the time. fetchmail is also intended to run as a system daemon as part of a full-fledged mail system. This isn't always the case. Also, launchd not just initd, but crond per Apple's consolidation of system daemons. That is a use-case for crond. If Apple wants to replace crond, then they should make sure that the replacement works. I'm sure that I could find other programs that might exit in under 60 seconds that don't have a daemon mode[1]. [1] To be clear it wasn't the 'run every minute' that was causing issues, but the 'exits less than 60 seconds after it starts' that was tripping it up. I could run fetchmail every 10 minutes, but when it is able to connect/verify that there isn't new mail in under 60 seconds, then the whole process gets disabled. Oops!