Why use nohup when the app can be run as system service?

Question

I put this question on stackoverflow, because I found lots of quesions on the topic here already.

Short introduction

Simply put, nohup can be used to run apps in the background and keeps them running after the user logs off or the terminal or ssh session is closed e.g.

There are many example quesitons here on stackoverflow, like this or that.

My question is simple.

Why opt for nohup, when there are options like upstart, systemd, ... which manage the app as service in a much more convenient way (runlevels, ...)?

Reading the many questions on similar topics, the only option seems to be nohup. Almost never the answer is something like: "... use an upstart script, so it is all handled for you..."

---

I would mainly go with e.g. upstart, except maybe for a quick and dirty test scenario.

Am I missing something important?

Answer 1

nohup is quick, easy, doesn't require root access and doesn't make permanent changes in the system. That's why many people use it (or try to use it) instead of configuring services.

Running things in the background without any supervision is usually a bad idea, although there are many legitimate use cases which don't fit traditional service model. For example:

1. Background process might be needed only sometimes, after certain user actions.
2. More than one instance might be needed. For example: one per user or one per session.
3. Process might not need to to be running all the time. It just quits after doing its job.

Some real world examples (which use something like nohup and would be hard to implement as system services):

1. git will sometimes run git gc in background to optimize repository without blocking user work
2. adb will start its service in background and keep it running until user asks to terminate it
3. Some compilers have option to keep running in the background to reduce startup times of subsequent invocations