search

capistrano / sshkit

A toolkit for deploying code and assets to servers in a repeatable, testable, reliable way.
MIT License
1.13k stars 253 forks source link

Bug: Background doesn't work as expected, should be deprecated and eventually removed #332

Open leehambley opened 8 years ago

leehambley commented 8 years ago

https://github.com/capistrano/sshkit/blob/6c81f53eec86443ea4f03fd87ae3350d4d4051ec/lib/sshkit/backends/abstract.rb#L59

The problem is that background simply nohup and backgrounds the process using the shell's job control &. More often than not, badly behaved daemons still block.

There's many hoops to jump through to ensure that your process behaves well when backgrounded, forked, nohupped, etc - and we can't whitelist programs that do it well, and blacklist those that can't.

Discussion is welcome, but I do think that background() should be removed from the DSL.

mattbrictson commented 8 years ago

I agree. IMHO daemons should be managed by the init process, not by Capistrano deploy tasks. The background method is encouraging bad practice.

leehambley commented 8 years ago

I agree. IMHO daemons should be managed by the init process, not by Capistrano deploy tasks.

Exactly, there's some legacy here, it used to be used for mongrel script/runner, and if you monitor a service with something like Monit, then starting it with Capistrano does make sense, sometimes.

maxwxzheng commented 7 years ago

What's the suggested way to execute a command in background? Or is it discouraged?

mattbrictson commented 7 years ago

What's the suggested way to execute a command in background? Or is it discouraged?

@maxwxzheng It is discouraged. SSHKit is typically used to deploy long-running processes, like app servers or job processors. In such a scenario, simply firing off the command in the background and hoping it stays running is not a good idea. What if the process dies? What if the server is rebooted? Instead, you should use a process manager like systemd which handles these things for you.