Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
We’re looking to run an application as a Service/Deamon on a Linux box without manually logging in and starting it. The application is a Java one that we start with a shell (.sh).
Do you know how to run a process on a Linux distribution as a service/deamon without logging in, manually start and stopping ?
Run a command on boot
You'd need to add the command that you would run, on /etc/rc.local.
Note: That path may be dependent on your distribution or init system, so check with the distributions documentation to make sure (ie it could be /etc/init.d/local or such).
One would typically
make that file executable -- chmod +x /etc/rc.local
and append/add in the contents the command that would run to start the application
$ echo "sh myscript.sh &" >> /etc/rc.local # or just edit with your prefered editor
Again, depending on your distribution and init system, you may need to add the file as a service on the default runlevel (or the appropriate runlevel)
sudo update-rc.d local defaults 80 # ie for ubuntu
Look at this howto for Ubuntu,
or look here for Archlinux,
or here for Gentoo
Remote part ?
The remote part has lots of trouble. What do you mean by remote ? Is the machine that runs the daemon in a Lan ? do you trust your lan ? does it communicate to the Internet ? etc
I would probably set up ssh on that machine, and whenever needed, I would log in and start/stop the daemon. You'd only need to set up sshd (typically /etc/ssh/sshd_config) and add ssh to run on boot.
If the machine is on a local Lan, and you believe that logging in and manually starting/stopping the daemon is too boring and want something more automated, I would probably write up a bot that would parse the mailbox for a specific user and upon receival of "special" mail, it would start or stop or toggle the status of the daemon (note it must have the appropriate permissions). That sounds easy, but you need to trust your lan or be careful on how you parse the mail (mail spoofing etc).
Assumption I assume you mean how you would get a Java service to start and stop at different run levels.
Take a look at the Java Service Wrapper it is an application which has evolved out of a desire to solve a number of problems common to many Java applications. The features of Wrapper are as follows:
Run a Java application as a Windows Service or UNIX Daemon
Java Application Reliability
Standard, Out of the Box Scripting
On Demand Restarts
Flexible Configuration
Ease Application Installations
Logging
The above spiel is from the website but I have used it extensively and its excellent. I can't recommend it enough.
In addition to other answers, you might use a #reboot crontab(5) entry
On Debian or Ubuntu, you could create your own service script by copying /etc/init.d/skeleton into your /etc/init.d/iccubedaemon (and edit that file appropriately) then symlinking it as /etc/rc2.d/S99iccubedaemon etc...
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.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I have added some environment variable as an export path to bash shell. Unfortuanately, I did it wrong and now I can't login to my account in Ubuntu.
Is it possible to remove these export commands from .bashrc, or can we directly replace this
bashrc to the one defined by the system like default?
I can't login even after entering the correct password, but at the same time I can login through guest account.
This might give some idea about the problem. I got this using Ctrl + Alt + F1 at the login screen.
Last login: Wed Jan 22 13:17:57 CET 2014 on tty1
Welcome to Ubuntu 12.04.4 LTS (GNU/Linux 3.8.0-35-generic x86_64)
* Documentation: https://help.ubuntu.com/
-bash: export: `:': not a valid identifier
-bash: export: `usr/local/SHTOOLS2.8/modules': not a valid identifier
-bash: export: `:': not a valid identifier
-bash: export' `usr/local/SHTOOLS2.8/lib': not a valid identifier
You need to get write access to the misconfigured start script (.bashrc). Can that be achieved via the guest account? I doubt it. Otherwise just edit your file using sudo pico /home/user/.bashrc.
You can always get write access by starting a runtime system from a Ubuntu boot disk. That on-the-fly system which starts then can mount the hard disks so you can then modify the .bashrc in question. I pray you are not using a crypted home directory.
You can also try out whether you can log in to your account via ssh (you need to have an sshd installed and running for that of course). If you can connect but the login stays broken, maybe you can at least execute commands via ssh: ssh user#host date (using date just for testing purposes). If at least this functions, we can start patching your broken script file via commands.
You have two problems:
(1) You need to re-gain system access
(2) You need to fix .bashrc
Solution:
(1) Problem#1:Regaining Access
(1)(a) If there is another user with sudoers permissions (i.e. the user can execute "sudo" to execute commands as root), then have that user log in and you will have access to the system to perform the solution to Problem#2.
(1)(b) if you do not have another user account on the system, you will need to boot from an Ubuntu or other live CD and mount the file system for repair operations to Problem#2. That is outside of the scope of this specific problem, but there are plenty of docs to that effect online.
(2) Problem#2:Repairing .bashrc
(2)(a) The simplest approach is to make a backup copy of .bashrc in your home directory, calling the bad file something like myBadbashrc. Then you can replace the file with a fresh .bashrc from /etc/skel or whereever your particular system gets its new-account template from.
(2)(b) If you don't feel like replacing the above file, you can do edits and continue testing through iterations.
(3) A footnote on .bashrc or other account maintenance. Always test with a TEST account. if you can't do that, then login under another terminal WHILE you are still logged in to make sure things work right. The good news: We have ALL done what you've just done and learned this lesson the hard way. ;-)
--Sam
This question already has an answer here:
Differences in controlling daemons & applications
(1 answer)
Closed 8 years ago.
This is a duplicate question from here:
Differences in controlling daemons & applications
only with updated tags so more people
can view it and comment.
Hi everyone,
With respect to this excellent post:
What's the difference between nohup and a daemon?
I would like to ask the following:
After launching an application from my terminal, the application keeps running either in the background or the foreground and the only thing I can do to interact with it is by sending it signals from my terminal (given that stdin is still in place).
However, after a daemon process is launched, I realized that it can be controlled with other means like querying it or restarting it (arch way):
# /etc/rc.d/daemon-name {start|stop|restart|status|...}
Could someone explain to me if that feature is built-into the general "daemon framework" and applies to every daemon process as a special feature or is it just a provision that processes designed to run as a daemon will have to handle internally?
And to add more to the matter, how on earth are we able to "control" daemons from the terminal using their name (i.e. sambad stop) while applications always have to be referred using their name (i.e. kill -9 1234)?
Thank you in advance!
This is done differently for different daemons. Just look into those files (/etc/rc.d/*) and see how it's done.
On debian most services use start-stop-daemon. PID is stored in a file and start-stop-daemon sends signals to that PID.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
We develop a Linux application to work on different RedHat/SUSE distributions. This application (namely, daemon) is expected to be automatically run at startup so we place our startup script in /etc/init.d/ directory and create symlinks in runlevel directories (../rc.d/rc5.d/, for instance). If a user removes our application, our uninstall script removes all our stuff including symlinks. It works fine if OS doesn't provide parallel script running. If parallel running is enabled, we need another solution. For instance, in SLES 10, we have in /etc/sysconfig/boot:
# Run all scripts or rather start/stop all services
# which are independent from each other in parallel.
RUN_PARALLEL="yes"
As far as we understand, we have to register our script with insserv utility. In this case, the system analyzes a script header and creates/removes symlinks on it's own. If it's true, how to organize installation/uninstallation of our application to cover both parallel and sequential startup script running? It looks like we should behave differently when parallel running is disabled or enabled. In first case, we should care about symlinks ourselves. In second case, we should delegate it to insserv. Is this right approach? If it's true, should we analyze whether parallel running is enabled by checking /etc/sysconfig/boot? It looks unreliable because in different Linux distributionsit could be different location and different parameter.
What's the best practice for installation/uninstallation Linux application that covers both parallel and sequential system startup?
Thanks,
You should use chkconfig to manage init scripts on RedHat and SuSE.