Pidfile is used in foreground mode about sftpcloudfs HOT 8 CLOSED

The pidfile is used as a lock to avoid two instances running at the same time.

The example configuration file is probably wrong as it says:

• default: empty; not correct as we use a default pid name.
• Pid file location when in daemon mode; not correct as we always create the pid file.

I'll make a bug report for that.

Regarding you question, I don't see the problem. upstart doesn't use pidfiles, but that doesn't mean you can start n instances of the same service trying to bind to the same port, and preventing that is one of the uses of the pidfile.

More information would be appreciated!

from sftpcloudfs.

IMHO, multiple daemons should be perfectly acceptable, as long as they listen to different sockets. The listening socket already acts as a mutex. The pidfile just reimplements that mutexing behaviour with files instead of sockets.

The main issue I have is that the current implementation doesn't deal with stale pidfiles. This isn't a problem as start-stop-daemon tends to deal with it by checking if the pidfile actually represents a valid running process. However, upstart doesn't manage the stale pidfile (it doesn't do pidfiles at all), so after an unclean shutdown, the daemon refuses to start due to a stale pidfile.

from sftpcloudfs.

There's no problem with that, but you need to specify different configuration files or CLI options (and hence different pidfiles should configured).

The pidfile provides a lock mechanism that is not equivalent to your operating system reporting an error binding to a port already in use.

If there's a stale pidfile that means the process is not being shutdown properly (otherwise it would be removed), and you should investigate that (no matter what we decide here!). Besides you may want to run the service using expect daemon (or similar, I'm not upstart expert), instead of using the foreground mode (that is intended only for troubleshooting).

I like that the pidfile has a default, and I never had a problem with it because the service always ends correctly, but getting back to you request, we could accept that no pidfile is created if it's not configured.

Take a look to this and tell me if it works for you:

https://github.com/Memset/sftpcloudfs/tree/no-pidfile

Thanks for your report!

from sftpcloudfs.

With correct documentation on the output, I would've created a working upstart script first time round, so that definitely helps. I still disagree on the purpose of a pidfile, but that's not really important.

If --foreground is only intended for debugging, you may want to include that in the documentation, too.

Are you by any chance interested in the resulting upstart configuration?

from sftpcloudfs.

We don't provide support for any init or process management system (we use classic init scripts mostly, although we have some deployments with supervisord).

Let me know if you like my proposal and I'll merge the changes.

from sftpcloudfs.

Yes, the foreground mode is not intended for production. If you use ftpcloudfs some functionality is not (or wasn't) even available because of limitations of that mode (not sftpcloufds case as paramiko does most of the heavy lifting).

from sftpcloudfs.

The proposed change looks good to me, thank you.

from sftpcloudfs.

Sorry about the docs not being completely clear. You can submit a pull request if you feel anything can be improved!

from sftpcloudfs.