On my raspberry pi, I want my own written server to be started at startup, and to be restarted when it segfaults, so I added it to /etc/inittab. The problem is that the server won't start
The line I added:
1:2345:respawn:/home/gear/lionfish/main /home/gear/lionfish/app
When I run this command from the command line it works just fine, but the server doesn't run. I've checked this with ps aux, and it didn't show up
Have I made some sort of mistake?
EDIT: Small side question. The server needs root privileges, does inittab do this automatically or do I need to add something to it?
Typical problems:
As already mentioned, environment is set up differently. Make sure $PATH iscorrect.
Does your program try to execute in a directory which becomes unmounted? If so, cd to / first.
Access restrictions to files and directories.
Process doesn't detach from stdin/stdout/stderr.
The process runs in foreground instead of background.
Parent process receives a terminating signal such as SIGTERM which kills your process as well. Try ignoring this (and some others) signals by using nohup or sigset/sigignore.
Debugging hint: Let the server start by appending current time to the end of an already existing file in a directory which is guaranteed to be writable. Make sure you flush (and close) the file pointer immediately. Then at least you can see whether it was started at all or not.
Related
I'm using the Mediatek 7688 board running OpenWRT linux to create an IoT device. I have written the app in NodeJS and want it to be executed anytime the board boots up.
I have tried the solution given [here] (How to auto start an application in openwrt?) while this works but the board seems to be unable to complete the boot process (the NodeJS app doesn't exit). I have also tried the pm2 npm module but am running into issues with diskspace during installation.
Is there a way to reduce the "installed" size of the pm2 module? Or maybe a way to fire up the NodeJS scripts upon startup without using the module.
Thanks in advance!
So I was only using the pm2 module to ensure that:
The program started at bootup
The program was restarted in case it crashed
To accomplish the first part and since my program was a node.js program, I made it into an executable file by adding #!/bin/sh env node as the first line in the file. Must ensure that the line ends in a LF line ending and not CRLF as in case of windows systems. Once done, I granted execute permission to the .js file by calling chmod a+x myfile.js.
I then created an init script in the /etc/init.d folder and enabled that script - as explained here
Now to ensure that the process restarted automatically in case it ever crashed, I a "cron script", like so and saved it a restart.sh in the root folder:
#bin/sh
if pgrep -f myfile.js > dev/null
then
#process is already running - do nothing
else
/etc/init.d/myprocess start
fi
And finally setup a crontab -e with * * * * * ~/restart.sh so that the restart.sh gets executed every minute to ensure that the process is running.
So, I can get the directory of dump.rdb's location to change by using the dir option in redis.conf when I start it normally (just calling redis-server). If I want redis-server to run all of the time (I do) without needing a terminal window always open, I think I need to daemonize it. However, it doesn't seem this ever persists to the disk automatically and whenever the redis-server process ends (I've been ending it in testing by just running redis-cli shutdown or sometimes just killing the process with kill PID) and starts back up, all database changes are lost, which seems pretty bad if a crash or unexpected shutdown were to happen in the future. In the code that runs the processing of data (either python with redis-py or java with jedis), I can explicitly run bgsave(), but that saves dump.rdb in the directory that the code was run in and not where the dir option specifies in redis.conf
So, is there either another way to run redis-server without requiring a whole terminal window to stay open that allows what I want to do or is there a way to get the data to persist on disk in the proper directory when it's run as redis-server --daemonize yes or similar?
You could put it on linux "background" using nohup. It does not need a terminal window to stay up and running. I don't know the daemonize option to give you an advice about that, but, see if it works for you:
nohup redis-server &> redis.log&
or
Set daemonize yes in the conf file and run:
redis-server path/to/redis.conf
I have a script (twoRules.sh) which add rules to ovs plugin bridge.
The rules gets deleted when someone does service neutron-plugin-openvswitch-agent restart or reboots the system. So where should I put my scripts so that after the restart of neutron-plugin-openvswitch-agent the (twoRules.sh) scripts get executed successfully and rules remain added.
I tried putting it in /etc/init.d/neutron-plugin-openvswitch-agent file as other people suggested but this file is only called on /etc/init.d/neutron-plugin-openvswitch-agent restart and not on service neutron-plugin-openvswitch-agent restart.
You have to convert the script to a a SysV-style init script. There are many documents out there explaining about this.
http://www.debian-administration.org/article/28/Making_scripts_run_at_boot_time_with_Debian
http://www.cyberciti.biz/tips/how-to-controlling-access-to-linux-services.html
https://wiki.debian.org/Daemon
This way you can configure the script to be executed after certain services start or stop or when runlevel changes.
We are finishing development of a project, the client is already using it but occasionally some errors occur - crashing the server.
I know I could register a service as 'upstart' script on linux, in order to have my node service restart when it crashes.
But our server is running other stuff, so we can't restart it.
Well, actually, while writing, I realize I have two questions then:
Will 'upstart' work without having to reboot? Something is just whispering yes to me :)
If not, what other option would I have to 'respawn' my node server when it crashes?
Yes, upstart will restart your process without a reboot.
Also, you should look into forever.
PM2 is a Production process manager for Node.js app.
If your focus for automatic restart is an always running application, I suggest to use a process manager. Process manager, in general, handles the node process(es if cluster enabled), and is responsible for the process/es execution. PM leans on the operative system: your node app and the OS are not so strinctly chained because the pm is in the middle.Final trick: put the process manager on upstart. Here is a complete performance improvement path to follow.
Using a shared server and not having root privileges, I can't download or install any of the previously mentioned libraries. What I am able to do is use a simple infinite bash loop to solve my issue. First, I created the file ./startup.sh in the base directory ($ vim startup.sh):
#!/bin/bash
while:
do
node ./dist/sophisticatedPrimate/server/main.js
done
Then I run it with:
$ bash startup.sh
and it works fine. There is a downside to this, which is that is doesn't have a graceful way to end the loop (at least not once I exit the server). What I ended up doing is simply finding the process with:
$ ps aux | grep startup.sh
Then killing it with
$ kill <process id>
example
$ kill 555555
I'm running linux on a mips based system (specifically openwrt on a router).
When I run the reboot (as supplied by busybox) i.e. just reboot on it's own, the system reboots, but some of the services (webserver, dhcp/dns, dsl stuff) don't start up.
However when I reboot via the web interface, all the services start normally. I looked at the code and saw that the web interface runs reboot > /dev/null 2>&1. Running this command also reboots and starts up0 the services properly.
My question is how does redirecting stdout and stderr to /dev/null affect the startup of services upon the next boot?
Also, I'm wondering, would reboot contain architecture specific code?
No, redirecting stdout/stderr must not be able to affect the boot process (and where would that be saved anyway?). There must be something else causing this.
Does "shutdown -r now" work?