-1

I'm running my RPi 'headless' with my laptop using wifi. The RPi is connected to the router with a LAN cable. I need to start the RPi running and leave - with my laptop. I'm currently using MobaXterm and SSH sessions to program the RPi. Eventually, the unit will manage a residential solar power station and I need full automation. If I turn the software into a daemon will that work? My current experience is that turning off MobaXterm shutsdown the program I'm running. Would a daemon keep on running? I have a choice between to management programs, one in PHP and one in Python.

Thank you, I decided to use systemd to make a service/daemon because cron will not perform under some system conditions. This is after I did some more research. If I do all the work, why do I need the Stack?

UPDATE: Since this post, I've developed the knowledge and skills to write services and timers. I believe sysvinit and cron to eventually becom deprecated and archaic. I subsequently learned to use systemd services and timers. I use setsid for some testing, but scripts that run successfully in setsid, will not do so as a service. I know, I just discovered that tidbit of knowledge. Services and timers with systemd are the future of automation in Raspbian, I believe, or at least from what I can tell form all the reading I've done on the internet.

The "Thank you" I wrote, was, in a response to someone who begrudged my asking for help. I appreciate help in the form of advice from an understanding of the problem, not quips from someone who wants to wants to project their shortcomings onto me.

Jim Julian
  • 1
  • 3

3 Answers3

3

If I turn the software into a daemon will that work?

Yes. The problem is possibly two-fold:

  • First, if you exit a remote shell with a process running in the foreground, that process will die right away. MobaXterm looks like it's more of a complete remote desktop, so analogously, if this is a GUI application, that will die when you close the remote desktop. If it's being run in the background via MobaXterm then this "first fold" is not an issue.

  • Second, even if it is running in the background, processes are created as children of other processes. When the parent of a process dies, if this doesn't immediately kill it as well (as per the first point), then it becomes an orphan. Ideally, orphans are re-parented by init, which never effectively dies (on Raspbian and GNU/Linux generally now, init is systemd), but under some circumstances they may die mysteriously anyway; a common cause for this is because the standard input or output stream gets closed, resulting in a SIGHUP. A common way to avoid this is to invoke the process using nohup.

However, a better solution than nohup for creating a daemon process ("a daemon" might be defined as something running in the background with init as its parent), is to use setsid. E.g.:

setsid myprogram &

The ampersand sends it to the background; setsid gets it properly reparented by init immediately without it being associated with a controlling terminal that when closed will lead to a SIGHUP.

Of course, if the process subsequently dies, it is going to be impossible to determine the cause unless you've included some logging -- some thoughts about that here.

Very often daemons are started as init services, which is a slightly more complex solution you may want to consider. This doesn't necessarily mean they are started at boot, it just means they can be started via (presuming init is systemd) systemctl start myservice. Doing things this way gives you some enhanced diagnostic options (e.g., systemctl status myservice will show you a process tree, give you the exist status if the primary process stopped, and timestamp various events).

setsid() is also a system call which any language that implements POSIX functionality (including python and php) should include. Daemonization is done programmatically via fork() (to create a duplicate child) with the parent exiting and the child invoking setsid(). Beware there are some nuances involved with forking depending on what resources have already been initialized and what the general state of the forking process is.

Community
  • 1
goldilocks
  • 58,859
  • 17
  • 112
  • 227
0

I would suggest to put the program on cron and you can put something like this

sudo crontab -l
@reboot <path_to_the_script_that_invokes_the_program>

So even if the system reboots due to power fluctuation your program will be up and running. So just make your script ready for running the process.

Let me know if this answers your question. Also let me know if you need more detailed description.

Varad A G
  • 848
  • 6
  • 17
0

I decided to use systemd. The trend tends to be toward the use of systemd over others, so I don't have to worry about obsolete software anytime soon. Chron will not run under some situations where systemd will. Systemd has a timer variant I can use if needed. Thanks for the input.

Jim Julian
  • 1
  • 3