I'm currently designing a program that I want to run when my computer boots up. I've written a daemon that runs the code, so what I want is a way to run the daemon on startup. Here's my problem: I don't want to my end user to have to manually add the daemon into their list of startup scripts, I want the daemon to be added automatically when the program is installed. At the moment I have a makefile that is installing the software to my pc, so is there a way to get the makefile to insert the daemon into the user's list startup scripts, so the daemon is run on startup?
Cheers
You could have some target (perhaps installcron) in your Makefile that would use the crontab(1) command to add (perhaps after verifying it is not there already) a crontab(5) entry for #reboot (which is run at boot time).
Related
I want my raspberry to execute 2 commands when he starts but i don't know how to setup it
the commands are
cd /var/www/restaurant && php -S 10.0.0.1:8000 -t public
i have tried to edit /etc/rc.local and add my command but it doesn't work
The "official" way to run a program at boot time on systemd-based Raspbian systems (and, in fact, most modern Linux distributions) is to create a systemd unit file. There are specific instructions for Raspbian here:
https://www.raspberrypi.org/documentation/linux/usage/systemd.md
The entry After=network.target is particular relevant in this case, because I imagine your program will need network interfaces to be up.
rc.local is a hold-over from the SysV init days, and I've heard reports of it not working reliably in Raspbian. Creating a systemd unit file provides a simple way to test the service using systemctl without actually having to reboot. If it fails on boot, you'll probably need to use journalctl to see the error messages.
I try to execute a java application at startup in a yocto based linux device. I added a script at /etc/init.d/etic and made it executable. If I call at the shell /etc/init.d/etic start or /etc/init.d/etic stop the application is started an stopped as expected. Then I called on the shell update-rc.d etic defaults and the symlinks were created. According to what I found on the web, this should be enough, but somehow the application is not started. What did I miss? How could I check what is going wrong or is there any minimal example which should work which I can try to extend?
Well, often such issues are due to a different environment when executing the start script by hand, as compared to when it's being run from the init system. For instance, your .profile and .bashrc won't have been sourced, when running from the init system.
You can use eg logger to easily log things from your init-script, and this rather easily find out what goes wrong.
I have a custom version of CENTOS that I need to run a perl script as a daemon in at all times.
To do this I want to get it to run on startup as a daemon.
When the machine is on I can daemonize the script with the command
daemonize /var/myfolder/myscript.pl
And this works fine.
So I have an rc1 script which has a number of commands that run when the machine starts, and the very last line in it is where I try to daemonize that script. Everything else in the rc1 script runs fine, and the script doesn't output any errors, however when I check to see if the daemon is running on start up, it isn't running.
Is there another way that I can get the script to run on startup? Or any ideas on why this method doesn't work?
Proc::Daemon offers what you're looking for.
See this previously asked question: How can I run a Perl script as a system daemon in linux?
The problem was that #INC hadn't fully loaded all of the modules by the time my script was called, and so my daemon wasn't running. I used the PERL5LIB command to add the appropriate directories.
PERL5LIB='/perl:/custom/lib:/usr/local/lib64/perl5' /var/myfolder/myscript.pl &
where /perl; /custom/lib and /usr/local/lib64/perl5 are the directories which were missing from #INC
I wrote a simple JAVA application which runs as a service. When my application is up and running, I maintain the PID in a file which will be used while stopping the application.
Issue:
When I restart the OS the stop script is not called (not sure how to make this happen) and the old PID is left as it is in the PID file. Now, after reboot (which start my app) when I stop the app using stop script now my stop script will try to clean up all the PID listed in the file. Most of the time, I will get "No such process". But there are chance the same PID might have been used for some other process
Question:
How I can make sure my stop script will be invoked when I shutdown ore reboot the OS? I am looking a solution for RHEL environment.
I think your are looking for a init script. (startup/shutdown services at different run levels)
This is a good reference
http://blog.rimuhosting.com/2009/09/30/one-java-init-script/
this has a good refernce to Linux init.d scripts
http://coreymaynard.com/blog/creating-a-custom-initd-script-on-fedora/
Hope it helps
If you are looking for scripts that run after reboot, I guess you can write the script in /etc/rc.local and then you can start your service.
This script will run after all your init scripts have run while your machine starts. Using this you can delete the old PID file.
I want to start a java program ( class ) when the system starts ( even though when no user has logged in the system ). I read some documentation and I found that Linux executes the init command when booting and executes the scripts in the rc.d directory. And the rc.local file is executed last. So I wonder if it is right to edit this file in order to run an application when the system has finished booting up ?
It depends. If your program
is a purely local modification and
you don't need daemon control over the software (start/stop it later at system run) and
a simple SIGTERM suffices to stop your program on system shutdown,
then yes, rc.local is just the point to put it.
If you intend to install the file on other systems, put a file in /etc/init.d and use the system specific commands to let it run at the appropriate runlevels.