I have a script to start and stop my services. My server is based on Linux. How do I automate the process such that when OS is shutdown the stop script runs and when it is starting up, the start script runs?
You should install init script for your program. The standard way is to follow Linux Standards Base section 20 subsections 2-8
The idea is to create a script that will start your application when called with argument start, stop it when called with argument stop, restart it when called with argument restart and make it reload configuration when called with argument reload. This script should be installed in /etc/init.d and linked in various /etc/rd.* directories. The standard describes a comment to put at the beginning of the script and a uitlity to handle the installation.
Please, refer to the documentation; it is to complicated to explain everything in sufficient detail here.
Now that way should be supported by all Linux distribution. But Linux community is currently searching for better init system and there are two new, improved, systems being used:
systemd is what most of the world seems to be going to
upstart is a solution Ubuntu created and sticks to so far
They provide some better options like ability to restart your application when it fails, but your script will then be specific to the chosen system.
Related
Requirements:
I want to run my application on linux in the background (at startup of course).
I want to be able to call start/stop/restart commands directly from console (it have to be simple just like for /etc/init.d - just call simple command directly from console).
I want to be able to call status - and I want that this command will somehow get the actual status of application returned by itself. I thought that I can call some method which returns String or just use stdin to send command but when I do noup .. &, or start-stop-daemon, then the stdin is detached. Is there a simple way to attach stdin back to the application (I've seen that I can create a pipe, but this is pretty complitated). Or what is the best way to communicate with application after it is started as a daemon (I can make a socket and connect through telnet for example, but I am looking for simpler solution and possibility to do it directly from console, without starting telnet first)? Ideally it will be great to get the possibility to send any command, but simple status will be sufficient (but again - it have to communicate with the application to get that status somnehow)
I have found many different answers. Some of them says to simply use nohup and &, and some others says that nohup and & is old fashion. Some answers says to use start-stop-daemon or JSvc (for java). But it seems that none of them will suffice this 3 requirements from me.
So... What are the simplest possibilities for all of 3 requirements to be met?
PS. I don't want to use screen. The application must be run as a linux daemon.
PPS. Application is written in Java but I am looking for generic soluction which is not limited to java.
You should create a command line tool for communicate with a daemon in way you need. The tool itself can use TCP/IP or named pipes.
And then use cli-tool start|stop|restart|status from console.
If you need to start a daemon at startup sequence (before user login) you have to deal with init system (init.d, systemd, OpenRC, etc...).
Dragons be here:
Be sure that init doesn't restart your daemon after manual stop via cli.
Command line tool itself runs with unprivileged user rights, so restart may be hard if first startup script use superuser rights or application-specific user and, especially in case deep init integration, you might have to use sudo cli-tool start.
To avoid this one possible solution is to make wrapper daemon, that runs forever via init and control the underlying application (start-stop) with proper rights.
Cons: Develop two additional tools for a daemon.
Pros: Wrapper daemon can operate as a circuit breaker between superuser/specific user and userspace.
In the Supervisord conf files you can specify to autorestart a certain program with:
autorestart=true
But is there an equivalent for [Supervisord] itself?
What is the recommended method of making sure Supervisord continues running unconditionally, especially if the Supervisord process gets killed.
Thanks!
Actually your question is a particular application of the famous "Quis custodiet ipsos custodes?" that is "Who will guard the guards?".
In a modern Linux system the central guarding point is init process (the process number 1). If init dies, the Linux kernel immediately panics, and thus you have to go to your data center (I mean go afoot) and press reset button. There're a lot of alternative init implementations, here is one of those "comparison tables" :)
The precise answer how to configure a particular init implementation depends on what init version you use in that system. For example systemd has its own machinery for configure service restart upon their deaths (directives Restart=, RestartSec=, WatchdogSec= etc in a corresponding unit-file. Other init implementations like Ubuntu Upstart also has its analogues (respawn directive in a service configuration file). Even old good SysV init has respawn option for a service line in /etc/inittab, but usually user-level services aren't started directly inittab, only virtual console managers (getty, mgetty etc)
I want to create an application that runs in the background in Linux (daemon) that will basically at set times (5 times) play a music file or any sound given every single day. I want this daemon to start when the computer is started in terminal mode (non-GUI). I want to know if this is possible and if so, What considerations, tools, and programming language would be the most efficient in doing so? This will be a dedicated computer that will only be executing this task, so if any recommendations on how I can maximize efficiency while disabling other features that are not required for this task will be appreciated. Also, could you please explain how processes and tasks work in terminal (non-GUI)? I always thought terminal was something like CMD in Windows and can only run tasks one at a time.
EDIT: I need the sound to run at variable times, I'll be fetching these times from a website. Any suggestions regarding how to achieve this?
Thanks for the help and sorry for any shortcoming in the questions or my research.
Look at using cron to run your tasks. cron is a very flexible scheduling utility built in to most Linux distributions.
Basically, with cron you specify a task to run (your main program, or maybe just a sound-playing program), all of its arguments, and when it runs. cron takes care of running it, and will even send you "mail" if the job produces any output (such as errors).
You can make processes fork into a subprocess of your terminal, i.e. you are able to run more than one task at a time by putting a & after your terminal command:
> cmd&
> [you can type other commands here but the "cmd" program is still running]
However, for services you generally don't have to worry about starting it as a subprocess because the system already knows to do this. Here's a good question from Super User that has an example of a working service. Simply place your service as a shell script in the /etc/init.d and it will be automatically started as a service.
I'm interested in how rebooting is implemented in Linux. When I press ctrl-alt-del or click "restart" in the menu bar, what happens next?
Thanks!
brings the system down in a secure way. All logged-in users are notified that the system is going down, and login(1) is blocked. It is possible to shut the system down immediately or after a specified delay. All processes are first notified that the system is going down by the signal SIGTERM.
It does its job by signalling the init process, asking it to change the runlevel. Runlevel 0 is used to halt the system, runlevel 6 is used to reboot the system, and runlevel 1 is used to put to system into a state where administrative tasks can be performed;
So basically reboot calls the "shutdown".
Quick answer is that all the scripts that are in /etc/rc6.d are executed.
scripts that start with "K" are executed with the "stop" parameter.
scripts that start with "S" are executed with the "start"parameter.
For more you can start reading about runlevels here: http://en.wikipedia.org/wiki/Runlevel
There are different init systems on Linux, and they also control what happens on restart/shutdown. See https://unix.stackexchange.com/questions/18209/detect-init-system-using-the-shell to tell which you're using.
If you're using SysVinit, then there is a runlevel associated with the overall system status. The init system will first run all the kill scripts associated with your current runlevel and then the start scripts associated with runlevel 6. If your current runlevel was 5, it would run /etc/rc5.d/K* and then /etc/rc6.d/S*. They might be in another directory, such as /etc/init.d/rc5.d/k*, depending on your Linux distribution.
If you're using systemd, then instead of having an overall "runlevel", there would be a list of defined targets and services. A list of targets is essentially a runlevel. These are defined in .service and .target files under /etc/systemd. There will likely be a "reboot.target" defined under there, and other services with a dependency on that will be run on reboot. See the systemd homepage or this stackexchange question for an example.
Some Ubuntu versions also use upstart, but I think it's been replaced by systemd in more recent versions. If you are using upstart, see this guide or this askubuntu question.
One thing to be careful of is that regardless of which init system you're using you may be using init scripts generally associated with another one. So you may be using sysVinit, but some of the rc*.d scripts may be links to things that invoke systemd scripts. Or vice-versa.
I am a node.js developer. I use Amazon ec2 to deploy my node.js apps.
I want to have my node.js service running permanently - restarted if it fails for any reason.
I came across 2 tools . Forever and Upstart
Is there any advantages of using one over the other ?
Is there any other tool which is better ?
Upstart is a system service controller, similar to SysV Init and will start/stop/restart essentially any service registered for it, Node.js-based or not, and it will also automatically start services on system start for you. But Upstart is essentially specific to Ubuntu, and Upstart-specific services won't run on other Linux distros.
Upstart has a SysV Init compatibility layer that you could target,instead, to maintain as broad of a compatibility layer as possible.
Forever is a Node.js application that monitors and restarts other Node.js applications as needed, and as defined by its configuration JSON. Lots of options and fine-grained control over your service without the effort that would be needed to duplicate it in a custom SysV Init script. However, Forever isn't a system service, so if the server is restarted, you'll have to manually start your forever scripts again.
Beyond that, if all you need is something that will restart your script if/when it crashes, and you don't care about it starting automatically on system start, all you need is a bash script as simple as:
#!/bin/bash
while true
do
node ./myScript.js
done
Just to correct a misleading statement in the accepted answer...it is not true that upstart is an Ubuntu-only technology. See:
https://serverfault.com/questions/291546/centos-6-and-upstart
http://searchenterpriselinux.techtarget.com/tip/RHEL-6-ditches-System-V-init-for-Upstart-What-Linux-admins-need-to-know
http://en.wikipedia.org/wiki/Upstart#Adoption
With that, I think it is a much more compelling solution.