8 ms·

Immortal – A cross-platform, OS-agnostic supervisor for Unix-like platforms

78 points by tete 10y ago

zie 10y ago
This is pretty much a non-problem for us anymore. We use nomad (www.nomadproject.io) as a distributed process manager(and scheduler), it also does lots and lots of other cool things as well, but it also happens to handle this use case, as a sort of side-effect of what it does.
michaelmior 10y ago
Curious why I would use this over supervisord. It's a shame there's no comparison.
- interfixus 10y ago
  If for no other reason, because Python. It's an aesthetic thing mainly, and a bit silly I'm sure, but dammit, I find it unsettling to have my Python 3 stuff running, and then the legacy Python 2, simply for the sake of supervisord. Likewise, I don't need any Python on my Go-server, please.
  - dottedmag 10y ago
    It has already got systemd, so why another layer?
  - michaelmior 10y ago
    Yeah, I get that. Although I don't see it as a big deal since most systems have Python installed by default these days.
  - IgorPartola 10y ago
    That is sort of a misguided attitude. If you run Ubuntu, you run plenty of systems stuff on Python. Also Perl and bash and C. If the piece of software works and doesn't require you to do extra shit to set it up, who cares what it's written in? I can see caring about performance. A Python process will be more memory hungry than something hand coded in C. But for the rest of it, who gives a crap if t is packaged well. And if it's not, it's probably not worth using it at all.
    - interfixus 10y ago
      I give a crap. Also, I don't run Ubuntu. As I said, it's a question of aesthetics, and probably quite irrational, possibly OCD, but I do like my servers tight.
- nbari 10y ago
  Maybe this https://immortal.run/post/nginx/ https://immortal.run/post/nginx/
- arunc 10y ago
  Supervisord doesn't respect pam, limits.conf, etc which is a deal breaker for most of the stuff we do. I'm not sure if immortal solves it, but I might look into it.
dsr_ 10y ago
This appears to be aware that it is solving the same problem as daemontools / runit / nosh / s6... but doesn't seem to offer anything new or better. And it presents a solved problem (some daemons fork themselves off and the parent exits, so tell them not to do that or use fghack) as a new thing that Immortal can solve. Is there something actually new and interesting about this that I'm missing?
- subway 10y ago
  But this one is written in Go!
- tyingq 10y ago
  There is a "why another supervisor" explanation here: http://immortal.run/about/ http://immortal.run/about/ Mostly, though, covering the point about parent forks and exits that you mention.
  - elcritch 10y ago
    Thanks for the project, looks great!
- elcritch 10y ago
  The "execution" seems better at first blush. The documentation is short and to the point, which means it's something which would lead me to use it, especially since I still haven't figured out how to easily deploy most of the others you mention. The ability to have go produce cross platform binaries would ease a lot of deployment issues as well. Along with distributed logging, it's something I'll probably try using. Unless any of the above have advantages, primarily in the ease of use category.
- nbari 10y ago
  Instead of using named pipes for managing the process, a Unix socket is been used, so if required this opens the possibility to manage via a web JSON API the services an example about how to use Nginx for this is here https://immortal.run/post/nginx/ https://immortal.run/post/nginx/ The idea behind was to avoid a developer to deal with a DevOps/operator to just stop/restart services, something useful on staging environments. For starting, stopping a process there is no need to unlink/link a file, this simplifies things a little bit, for example, https://immortal.run/post/ansible/ https://immortal.run/post/ansible/ by only updating the file contents or "touching" the file it can be started or re-started. When following a PID, signals can still be sent to the process, these things become handy while working with a lot of microservices. The docs need to be improved, but any feedback, comments or even desired feature is more than welcome.
rektide 10y ago
I really like that it has a user-mode incarnation that looks in ~/.immortal. One of the things I really enjoy about Master Control Processes is having a well-declared place where one can expect to find a manifest of processes.
aerioux 10y ago
Is there more comprehensive docs anywhere? I want to know what options to pass, and more detailed descriptions of what things do. The initial docs page looks like but after clicking through it seems like they all link to each other... so in summary I cant find anything I want :/ That currently would be the primary barrier to usage -- the docs arent very helpful.
- nbari 10y ago
  Maybe this can help, https://immortal.run/post/ansible/ https://immortal.run/post/ansible/
- JdeBP 10y ago
  There are proper manual pages, immortal(8) and so forth, in the package itself.
norswap 10y ago
What would have made this a smash hit: Windows support. There is still no reasonable truly cross-platform way to deploy daemons.
- deleted 10y ago
  [deleted]
- zie 10y ago
  nomad (https://www.nomadproject.io/downloads.html https://www.nomadproject.io/downloads.html) supports Windows.
  - norswap 10y ago
    "A Distributed, Highly Available, Datacenter-Aware Scheduler" is a bit more than what I want. I just want a cross-platform way to install/remove (and query the status of) a daemon process (i.e. run your process as a Windows service, launchd service, or linux equivalent: systemd, ...).
    - zie 10y ago
      I agree, it's a little over-kill for your particular use-case, but it works well, and it can be run in -dev mode, so you don't have to use the whole distributed, HA and datacenter part(s). I don't have much experience with it on windows, but I use it regularly on *nix platforms and it works wonderfully.
vor1968 10y ago
These supervisor projects are always a chuckle. Is anyone ignorant enough to believe that any monitor can survive general process failure or contribute to recovery of a system with abnormal function or resource starvation? And that is the basic reason for these monitors! garbage. My last experience was with bluepill which was this mess of ruby nonsense. Anyone with any experience knows you can't trust a system to correct it's own failure. Why are we hammering this nail over and over to catch a 30% recoverable transient...management.
- nbari 10y ago
  I think that's why they are external "monitoring" tools to check how the status of your services and rather than just restarting a daemon, the ones if required could add more instances, restart them or rebuild everything, maybe something like https://epazote.io/ https://epazote.io/
- skarnet 10y ago
  You need to read the archives of the supervision mailing-list at list.skarnet.org, as well as http://skarnet.org/software/s6/overview.html http://skarnet.org/software/s6/overview.html - there is a lot of value in process supervision, it's just that most people who whip up their own solution end up doing it wrong. Like crypto, in a less dramatically noticeable way.
agnivade 10y ago
Ah nice. Something fresh and written in Go. I was wary that I will have to learn systemctl again for Ubuntu 16.10 after learning upstart. I want to use Immortal instead of systemctl. Just a question - is this mature enough to be used in production systems ?
- nbari 10y ago
  For avoiding having issues, try to compile from source on your target platform, this is due the https://golang.org/cmd/cgo/ https://golang.org/cmd/cgo/ the readme file has some instructions about how to do it: https://github.com/immortal/immortal/ https://github.com/immortal/immortal/ Regarding if is mature enough, strictly talking still not a stable version, current beeing `0.11.0` and not jet a `1.x.x` but the more you could test and evaluate could be nice. Please feel to raise any issue if needed here: https://github.com/immortal/immortal/issues https://github.com/immortal/immortal/issues
  - agnivade 10y ago
    Thanks !

78 points by tete 10y ago

zie 10y ago

This is pretty much a non-problem for us anymore. We use nomad (www.nomadproject.io) as a distributed process manager(and scheduler), it also does lots and lots of other cool things as well, but it also happens to handle this use case, as a sort of side-effect of what it does.

michaelmior 10y ago

Curious why I would use this over supervisord. It's a shame there's no comparison.

interfixus 10y ago
If for no other reason, because Python. It's an aesthetic thing mainly, and a bit silly I'm sure, but dammit, I find it unsettling to have my Python 3 stuff running, and then the legacy Python 2, simply for the sake of supervisord. Likewise, I don't need any Python on my Go-server, please.
- dottedmag 10y ago
  It has already got systemd, so why another layer?
- michaelmior 10y ago
  Yeah, I get that. Although I don't see it as a big deal since most systems have Python installed by default these days.
- IgorPartola 10y ago
  That is sort of a misguided attitude. If you run Ubuntu, you run plenty of systems stuff on Python. Also Perl and bash and C. If the piece of software works and doesn't require you to do extra shit to set it up, who cares what it's written in? I can see caring about performance. A Python process will be more memory hungry than something hand coded in C. But for the rest of it, who gives a crap if t is packaged well. And if it's not, it's probably not worth using it at all.
  - interfixus 10y ago
    I give a crap. Also, I don't run Ubuntu. As I said, it's a question of aesthetics, and probably quite irrational, possibly OCD, but I do like my servers tight.
nbari 10y ago
Maybe this https://immortal.run/post/nginx/ https://immortal.run/post/nginx/
arunc 10y ago
Supervisord doesn't respect pam, limits.conf, etc which is a deal breaker for most of the stuff we do. I'm not sure if immortal solves it, but I might look into it.

dsr_ 10y ago

This appears to be aware that it is solving the same problem as daemontools / runit / nosh / s6... but doesn't seem to offer anything new or better. And it presents a solved problem (some daemons fork themselves off and the parent exits, so tell them not to do that or use fghack) as a new thing that Immortal can solve. Is there something actually new and interesting about this that I'm missing?

subway 10y ago
But this one is written in Go!
tyingq 10y ago
There is a "why another supervisor" explanation here: http://immortal.run/about/ http://immortal.run/about/ Mostly, though, covering the point about parent forks and exits that you mention.
- elcritch 10y ago
  Thanks for the project, looks great!
elcritch 10y ago
The "execution" seems better at first blush. The documentation is short and to the point, which means it's something which would lead me to use it, especially since I still haven't figured out how to easily deploy most of the others you mention. The ability to have go produce cross platform binaries would ease a lot of deployment issues as well. Along with distributed logging, it's something I'll probably try using. Unless any of the above have advantages, primarily in the ease of use category.
nbari 10y ago
Instead of using named pipes for managing the process, a Unix socket is been used, so if required this opens the possibility to manage via a web JSON API the services an example about how to use Nginx for this is here https://immortal.run/post/nginx/ https://immortal.run/post/nginx/ The idea behind was to avoid a developer to deal with a DevOps/operator to just stop/restart services, something useful on staging environments. For starting, stopping a process there is no need to unlink/link a file, this simplifies things a little bit, for example, https://immortal.run/post/ansible/ https://immortal.run/post/ansible/ by only updating the file contents or "touching" the file it can be started or re-started. When following a PID, signals can still be sent to the process, these things become handy while working with a lot of microservices. The docs need to be improved, but any feedback, comments or even desired feature is more than welcome.

rektide 10y ago

I really like that it has a user-mode incarnation that looks in ~/.immortal. One of the things I really enjoy about Master Control Processes is having a well-declared place where one can expect to find a manifest of processes.

aerioux 10y ago

Is there more comprehensive docs anywhere? I want to know what options to pass, and more detailed descriptions of what things do. The initial docs page looks like but after clicking through it seems like they all link to each other... so in summary I cant find anything I want :/ That currently would be the primary barrier to usage -- the docs arent very helpful.

nbari 10y ago
Maybe this can help, https://immortal.run/post/ansible/ https://immortal.run/post/ansible/
JdeBP 10y ago
There are proper manual pages, immortal(8) and so forth, in the package itself.

norswap 10y ago

What would have made this a smash hit: Windows support. There is still no reasonable truly cross-platform way to deploy daemons.

deleted 10y ago
[deleted]
zie 10y ago
nomad (https://www.nomadproject.io/downloads.html https://www.nomadproject.io/downloads.html) supports Windows.
- norswap 10y ago
  "A Distributed, Highly Available, Datacenter-Aware Scheduler" is a bit more than what I want. I just want a cross-platform way to install/remove (and query the status of) a daemon process (i.e. run your process as a Windows service, launchd service, or linux equivalent: systemd, ...).
  - zie 10y ago
    I agree, it's a little over-kill for your particular use-case, but it works well, and it can be run in -dev mode, so you don't have to use the whole distributed, HA and datacenter part(s). I don't have much experience with it on windows, but I use it regularly on *nix platforms and it works wonderfully.

vor1968 10y ago

These supervisor projects are always a chuckle. Is anyone ignorant enough to believe that any monitor can survive general process failure or contribute to recovery of a system with abnormal function or resource starvation? And that is the basic reason for these monitors! garbage. My last experience was with bluepill which was this mess of ruby nonsense. Anyone with any experience knows you can't trust a system to correct it's own failure. Why are we hammering this nail over and over to catch a 30% recoverable transient...management.

nbari 10y ago
I think that's why they are external "monitoring" tools to check how the status of your services and rather than just restarting a daemon, the ones if required could add more instances, restart them or rebuild everything, maybe something like https://epazote.io/ https://epazote.io/
skarnet 10y ago
You need to read the archives of the supervision mailing-list at list.skarnet.org, as well as http://skarnet.org/software/s6/overview.html http://skarnet.org/software/s6/overview.html - there is a lot of value in process supervision, it's just that most people who whip up their own solution end up doing it wrong. Like crypto, in a less dramatically noticeable way.

agnivade 10y ago

Ah nice. Something fresh and written in Go. I was wary that I will have to learn systemctl again for Ubuntu 16.10 after learning upstart. I want to use Immortal instead of systemctl. Just a question - is this mature enough to be used in production systems ?

nbari 10y ago
For avoiding having issues, try to compile from source on your target platform, this is due the https://golang.org/cmd/cgo/ https://golang.org/cmd/cgo/ the readme file has some instructions about how to do it: https://github.com/immortal/immortal/ https://github.com/immortal/immortal/ Regarding if is mature enough, strictly talking still not a stable version, current beeing `0.11.0` and not jet a `1.x.x` but the more you could test and evaluate could be nice. Please feel to raise any issue if needed here: https://github.com/immortal/immortal/issues https://github.com/immortal/immortal/issues
- agnivade 10y ago
  Thanks !