I’m not terribly good with Linux and after searching for a cause, the only answer I can find for a console app crashing/not daemonizing is that it is not set up with a script during boot. However, I thought (from windoz world) that even a daemon or service app can be run from command line and run as a service (in windows world) or daemon in Linux land.
Can anyone shed some light on this to help me?
This is the code used:
#if TargetLinux then
If (args(1) = "start" or args(1) = "-d") then
If Not App.Daemonize then
System.Log( System.LogLevelCritical, "Could not daemonize the application")
Return -1
end
end
#Endif
In this case, it is compiled as Linux ARM console app.
In Linux you can execute a command and put it into the background simply by putting “&” after the command.
For instance: /my/App &
Depending on the shell you may find it still disconnects when you log out, in which case you can use the nohup command like this:
nohup /my/App &
For a more robust solution, launch your daemons using your OS’s init system. Usually upstart or systemd nowadays, but there are others. It is no more complicated then putting a config file in a directory and issuing a command or two. This provides a lot of benefits such as automatic startup, shutdown, restarting on crash, control over logs, control over environment and control over user:group the app executes under, etc…
I did use the wrong terms to describe the action - it is not daemonizing. The system log shows the failure to daemonize.
I was launching from a terminal, is that not the best way to do it for non-production (for testing) use? Also, in my console command, I am not including an amperstand ‘&’. Should I?
John Royce brings up another question - will it only continue to run while logged into the console? If not then how to make that happen but start manually?
Also, to stop is it better to add a console command to the app that would allow it to shut down gracefully rather than using the system to kill it?
You certainly can launch a console app from the terminal, for testing or otherwise. You can also use the init system for this using a ‘restart’ command (depends on your system). If you update your app files with new ones, then issue a restart, you have the new app. Either way is fine, it depends on you and your needs really.
I believe that the app.daemonize command is supposed to put the app in the background (return you to a prompt). But, you can also add a & at the end of the command and it will also launch it in the background.
If you are starting the app from the command line via a terminal then it may indeed quit the app when you log out. To prevent this you can launch it into the background as a daemon using any of the methods we are discussing here. Sometimes & is not enough to prevent termination on logout in which case you need nohup - OR - use the init system.
How graceful it needs to be is really a function of how your app is written and what it is doing. If there are open files or half written database queries I suppose it could cause problems if you kill it at the wrong moment. I guess you need to weigh those risks. I kill or restart my apps whenever I am updating them and I have never had any issue. However, I use transactions in the database and other protections against data corruption.