No, it's a train wreck of bad design, lack of backwards compatibility and sharp edges:
* Tracks PIDs only, so make sure that your process doesn't double fork (as many unix daemons do by default) or it'll lose track of them.
* No real documentation from Apple (man page is useless). The best resource is http://launchd.info.
* No feedback to commands: launchctl doesn't give any useful output about whether a command worked or not.
* Even something as simple as disabling a daemon may require manually editing one of the many `overrides.plist` XML files somewhere on the system.. though check your OS version because this changed between 10.9 and 10.10 without notice.
* ...I could go on.
Due to the chronic lack of documentation, many operations are totally trial and error. In fact, it is so bad that there's a market for a GUI tool (LaunchControl) which, to its credit, does manage to make launchd less painful than a trip to the dentist.
The only feature it adds that sysv didn't have is socket activation, and it doesn't do anything that xinetd didn't.
Makes it easy to set up your own launchd entries and manage existing ones, both user and system. I set up an rsync script to sync my photos with my NAS when I'm on my home wifi automatically.
I like it so much I bought it. There is no registration or serials or copy protection (IOW paying is optional) but after using it for a few weeks I felt like the asking price of $10 was more than justified for the utility I received from this utility.
Not too bad, but it could do with a more modern UI. The fact that it doesn't add all of the user's launch daemons to the "quick launch" menu by default is a bit of a missed opportunity.
But launchd can also be a pain in the ass -- just ask anybody who tried to make a sandboxed app with a helper tool. Launchd is poorly documented once you go beyond the basics. Some things that should be simple are almost impossible, eg. trying to find out where a job with a certain label is coming from. Some parts of macOS (eg. ServiceManagement) use hidden, undocumented interfaces to launchd, and if something goes wrong with them there's no way to fix it except create a new user account. And for no reason at all that stuff changes with new releases of macOS.
I understand why some people may prefer a simpler tool.
Interesting. Initially I chose to use helper tool to run sudo commands. After wrapping all those poorly-documented Authorization/ServiceManagement/XPC C APIs into Swift 3, I was like, sh*t, lemme just use askpass. Also, many of those APIs are deprecated in newer version of macOS and it's unclear that when Apple will remove them. That said, I can see the HUGE benefits of using launchd under the hood.
1. This tool is not something I'd use but if I were a casual user I'd appreciate it not changing my system configuration. Chances are if I want something like Marathono I don't want to be bothered with launchd. Also, if I delete the app I don't want to be left with "zombie" processes that I don't understand how to stop.
2. I love lunchy [1] (now ported to Go [2]), it's a simple launchctl wrapper that you can install with brew cask.
Another cool feature could be to link up with Homebrew services. Redis/ES/nginx/etc are mostly installed through brew, and 'brew services' provides a convenient shortcut to status/restart/stop/view status of those apps.
Having Marathono popup function as a proxy for Homebrew-managed services would give me a single dashboard for my development daemons, including infrastructure and my own app codes.
> Redis/ES/nginx/etc are mostly installed through brew
Consider using Docker/Docker Compose for this. It then becomes as easy as defining the image name and version, pulling it, and then starting the container. No brew, no version conflicts, it just works.
Absolutely, Docker makes these services easy to deploy. Unfortunately I'm the only one on the team using it - everyone else is deeply entrenched with Brew, hence I'm asking for them.
In defence of the team, the Docker value prop on macOS is fundamentally undermined by the broken shared volumes. Folders that are shared with the hosts are still unusably slow for larger projects, so we can't use them (docker-sync makes it better, but adds another layer of complexity). Further, a lot of tooling and IDEs still expect local files and a local interpreter for step-debugging. So if the files are on the host, and so is node/php, then docker adds no dev value for app-level work. CI, yes, local dev - not so much. From there, it's a slippery slope - if I already have app stuff on the host, might as well install infrastructure stuff too because it doesn't really change so why should I deal with another virtualisation layer. It'll be an uphill battle until Docker volumes work at native speeds on mac out of the box.
"LaunchControl" is another commercial GUI around launchd. It's pretty comprehensive and has an optional menubar presence. It also has some cool contextual hints and automatic fix suggestions that show up while editing/debugging the launchd jobs.
I'm at the point in my life where I simply don't trust free software that isn't open source. I've been burned too many times.
Either charge me money so we have a legal bond, or open source it.
Free closed source is untrustworthy software that may just disappear/break with no respite.
If it's open source and you stop maintaining it, I can fix it myself or at least try to. It if isn't, I'm screwed. I won't become dependent on software I can't trust to work years from now - I don't need that in my life.
I get your point, and I do agree. However it isn't uncommon for free closed software to become opensource if the owner can't or doesn't want to maintain it anymore.
Or atleast, that is how I handle free software that I create. As long as I'm the only maintainer and can maintain it, I'll keep it closed source. However if I can't or don't want to maintain it anymore I'll opensource it.
Not saying this is the case here, but just trying to say free and closed source software isn't always bad. :)
Why do you assume Open Source is really any better?
Have you seen the absurd number of 'Go download the latest version of this dep from some 3rd party remote host' steps in the build processes of modern software (oss or not)? Or my favorite 'Just use this image we pushed to dockerhub as your startingpoint for building our software'.
Because I can at least try to fix it when it fails. I'm not completely helpless. I can't simply have the rug pulled out from under me.
I've had a fair number apps in recent years, particularly those sold in the App Store that had become vital parts of my workflow entirely stop working after OS upgrades, and the author no where to be found.
It's not that it is inherently better, is that a good open source software has fewer chances of becoming an abandonware (and can brought back to life if need be)
I feel a bit discouraged from trying it by the uncertainty about the eventual price. I guess they're going to start charging for it at some point and that's ok. But I'd like to know a broad range before I start depending on it.
The "may start charging for it" piece is mostly for stopping people from asking me to open source the app. If I do start charging money, it will probably be at the price of a burger.
I'm the developer of PSequel (a popular PostgreSQL client, http://www.psequel.com/) and it has been free since it came out two years ago. I got people asking for open sourcing it almost every single day. Many people assume free == open source.
As an offender to this kind of behavior, I think it's more of a feeling that the only really compelling arguments against open-source apply only to commercial software, so you, the author of a free app, may be more easily convinced into open-sourcing.
And actually I'm curious, what would you say is your main reason for keeping the source code of your free tools private? (ugly code being a totally acceptable answer to which I can relate :))
As a developer that has closed source free programs and has run open source programs, sometimes I just don't want to deal with the extra effort of having to manage an open source project. This is usually true when I'm building something for myself but then share (for free) where I think others might enjoy using.
Well, open-sourcing doesn't mean you have to manage anything, it's perfectly fine to say you don't take any external contribution and expect people to fork the project if they want to.
Correct me if I'm wrong, "brew services" work for launchd services installed with homebrew only. But Marathono allows you to run any arbitrary commands.
I was thinking about making a terminal utility for doing this a couple days ago, the Mac app you made is so much better. I'll definitely be using this and upgrading to your paid version when you put it out.
The major annoyance I was having is when a long-running process dies, I might waste a couple minutes trying to figure out what's going on, only to realize that a gulp build stopped or some service crashed. Even if it only wastes a couple minutes here and there, the time and frustration add up.
Thank you for taking the time to make this available to everyone!
I think the name is okay. Marathon by itself would be a better name, though that I believe is taken by the Mesos task runner.
As for the logo, it's clever but too complex. It wouldn't bother me if it weren't prominent in the menu bar. Something more simple for the menubar icon could just be a ">" logo.
Pah. GUIs are for wimps. I use nohup $COMMAND &, or datch/tmux if I need to re-attach later. And listing your running daemonized processes is for wimps who can't use ps.
This looks fantastic. I could see this speeding up a lot of build processes for all sorts of devs. (Just realized, auto-compiling modified latex docs is another great use-case).
Hmm..I'm also using 10.11 with the dark theme. Does the app on your machine look very different from what I show in the second screenshot at http://www.marathono.com/? If it does, please consider reporting a bug thru the Help menu of the app.
I work mostly remotely by ssh-ing into the work ubuntu server from my macbook, so I don't really use the local terminal all that much. I've noticed in the past that the local osx terminal can be somewhat different from a standard terminal. Is there no screen or nohup in the local osx terminal for long running processes?
The use-case? Well, you have a process that will run for a long time. You don't want to keep a terminal open. You /could/ just detach it. Now what if you want to kill it? Open another terminal, kill it by PID or through pkill. Clicking a button might be more convenient.
>Marathono is a small GUI tool that helps you manage long-running processes in macOS, so you don't have to maintain multiple windows/tabs/tmux sessions in your Terminal.
How about one tmux session and a couple of windows? You could name the windows perhaps. I could see how this might not scale, but I bet my socks someone else has found a way to script this and make it easy.
I know we don't want to be overly negative on HN, but this doesn't sound like a problem that needed a completely newly rolled solution.
So you have GUI output. What if I want to grep or save it to a file? I can see how this will be usable for people who aren't comfortable with a terminal--as a someone who transplated linux-to-mac, I know how terrible the terminal experience is on mac.
EDIT: below I was corrected that Marathono does all manipulating text output, +1.
The main benefit for me is it saves all the commands you want to commonly run. So for things like an SSH tunnel, rather than having to keep some snippet around to copy/paste into that new tmux window (yes, I use tmux extensively), I can just put all the random SSH tunnel strings I need into one list, and turn them on/off as needed.
Also, I have to disagree with the terminal experience on the mac being terrible. Between iTerm and brew, I've never come across anything I couldn't do, but that could be done on linux.
I find that Windows developers seem more comfortable with GUI-heaviness in their dev environment, Linux developers seem less comfortable with it, and Mac is in kind of an odd gray zone in between. This seems fitting for the general style of the OS - sometimes sacrificing power to make things "just work" in a minimal UI.
There might be cases where I would find it useful but overall its usefulness is subjective and dependent on what you're looking for in your workflow/workspace.
Which seems like it would be a Big Deal, for a Mac user. The entire appeal of the Mac (for a developer) is that it layers a friendly GUI over a Unix-ey foundation. Presumably a user who values that GUI would also value GUI-oriented ways to do things that were previously terminal-only.
If "just use screen" was an answer that would make that user happy, they wouldn't have spent the extra money to buy a Mac in the first place.
The "Show Output" menu of Marathono opens a Terminal/iTerm tab to tail the output. Currently Marathono is designed for start-and-forget kind of processes - outputs are for occasional debugging purpose only.
Does this have to be the case? I have a couple of long running processes that I would really like to check the output of from time to time. Couldn't you have an option to just show the last line for example? Was super excited to see this as I've been bugged by exactly this but if I can't see the output it's a dealbreaker for me unfortunately
This feels like a caricature of Mac users. I mean, I like solid GUIs for graphical-friendly tasks. But launchd already exists and this doesn't even use that.
Launchd is a pain in the ass. And a poorly documented one at that. When they changed how it worked in a fundamental way somewhat recently (Yosemite I think) they couldn't even be assed to update their online documentation.
I wouldn't mind if this used launchd under the hood though.
Launchd is solid and full-featured:
* Good process management (failure retries with backoff)
* Supports watching folders
* Decent command-line client for when you want to script or work fast in the shell
* Supports starting daemons on login
* Can start/stop based on whether certain things (network, paths, mounts, etc.) are up/down
* Supports calendar-based scheduling (replaces cron)
* Can redirect logging
* Can enforce resource limits (RAM, CPU, I/O, number of processes etc.) + nice level
I run all my daemons (Homebrew apps as well as personal development stuff) under Launchd, and I would love a convenient menu-bar GUI like this.