Josh On Design

Or rather, re-introducing. I created AMX a few years ago when I needed to run some crash prone node processes on my server. AMX originally stood for something, but I can't remember anymore. I looked at existing tools and found them all overly complicated. In my mind a process manager is pretty simple. There's a list of programs that should keep running. If one stops, start it again. That's it.

Thus I decided to create my own. After all, how hard could it be? :)

Being more of a UI guy than a systems engineer I wrote the interface first. Each feature is built around a command: list, start, stop, info, etc. Want to get the info on a process called musicserver? Then just run amx info musicserver. Want to then restart it? amx restart musicserver. I tried to keep all commands simple with a simliar structure; and so far it's worked. I've been using it for nearly three years on my own server with no major bugs or missing features.

The name tail only makes sense if you are a programmer who understands how unix streams are implemented, so I went with something more semantic. There is one command I've often needed, however. You can view the current standard output log with amx log, but there was no way to view the error output, or to monitor it for changes the wait the unix tail command does. Thus today's release. With version 0.0.15 you can now use amx follow <taskname> to monitor both the stdout and stderr of your process at the same time.

You can get AMX yourself with npm install -g amx, or check out the source on github.