I have a java application running as a service on Debian. How to I make sure this service is restarted after the system reboots?
You can start with the documentation here
Debian makes use of System V-style init scripts for daemon management. This allows daemons to operate conditionally, based on the current RunLevel of the computer. For example, a daemon can be configured to run only when the computer is in single-user mode (runlevel 1) or, more commonly, when in multi-user mode (runlevels 2-5). For more information, see Init and RunLevel.
Related
I´m trying to install JBOSS EAP 7.4 on Windows Server as a service and I´m having trouble with two issues. All batch files where executed from the command line (cmd.exe) in admin mode.
Installation of Service with local system account
I´m using the service.bat to install it as a service. When checking in the properties of the service for the user context, it says it was installed under a Local Service user.This leads to numerous errors in the startup log, as the service is not allowed to access the file system in R/W mode. Manually setting this to “Local System Account” solves the problem, it runs just fine.
So, how do I configure the installation script that the service will use “Local System Account” or, how can I grant R/W access to this “Local Service”?
Shutdown
The manual states, that you must use the parameter /jbossuser (and password) for the installation. If I don´t, it is not possible to shut down the service via the Windows Services Tool, timeout…
If I add a user to the installation, it can be shutdown. As long as it runs in the “Local Service” context. If I change it to Local System Account, it doesn´t shutdown anymore, timeout…
Beside, this is a productive installation on a virtual server. It will not be possible to have a permanent, dedicated user on such a machine.
How do I configure this correctly?
Current installation params, generated by the service.bat:
"D:\jboss-eap-7.4.6\jboss-eap-7.4\bin\prunsrv.exe" install MyApp
--DisplayName=MyApp
--Description="JBoss Enterprise Application Platform 7"
--LogLevel=INFO
--LogPath="D:\jboss-eap-7.4.6\jboss-eap-7.4\standalone\log"
--LogPrefix=service
--StdOutput=auto
--StdError=auto
--StartMode=exe
--Startup=manual
--StartImage=cmd.exe
--StartPath="D:\jboss-eap-7.4.6\jboss-eap-7.4\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=D:\jboss-eap-7.4.6\jboss-eap-7.4\standalone#--server-config=standalone.xml"
--StopMode=exe
--StopImage=cmd.exe
--StopPath="D:\jboss-eap-7.4.6\jboss-eap-7.4\bin"
++StopParams="/c jboss-cli.bat --controller=localhost:9990 --connect --user=ABC --password='12345' --command=:shutdown"
Any help is appreciated!
I want to restart a service via init.d file on AIX. Ansibles service and sysvinit didn't work. How to control those services using Ansible.
I know I could run a shell command but maybe there is a builtin solution.
This is, what I would do on a shell:
/etc/rc.d/init.d/nrpe restart
From the docs of the service builtin:
Controls services on remote hosts. Supported init systems include BSD init, OpenRC, SysV, Solaris SMF, systemd, upstart.
Basically the service module tries to auto-detect which init system is used and perform the action using that init system. But if your init system does not know about the service (you are running the init script directly, right?) it (the init system) will not be able to restart it.
So you can not use the service module or any other module that tries to interact with your init system, if the init system is not aware of your service.
You should put your init script into the correct directory for your init system to recognize it (then you can also run service nrpe restart) and then use the service module.
If you can not do that for some reason, you will need to use the command or shell module to restart your service.
I have a ruby script (actually an example script from the Oxidized project), which is written in Ruby and opens a UDP port (514) listening for syslog messages and executing some code in the background.
The system runs on CentOS 7. I want to start this script as "service" automatically when the OS boots. The script however needs to run as a specific user (oxidized) and should be controllable using normal "service ... [start|stop|status|...|" behaviour. What would be the best way to achieve this?
Startup services can be managed by 2 different boot systems.
CentOS6 uses System V (Old Boot System)
CentOS7 uses Systemd (New Boot System) (Systemd does support System V scripts.)
Here is a link "How to write startup script for systemd"
https://unix.stackexchange.com/questions/47695/how-to-write-startup-script-for-systemd
Here is a link "How to write a System V init script to start, stop, and restart my own application or service"
https://www.cyberciti.biz/tips/linux-write-sys-v-init-script-to-start-stop-service.html
Does anybody know how to start sshd automatically on the BeagleBone Black ? I've replaced dropbear with OpenSSH. The standard systemctl enable sshd doesn't work, but strangely systemctl start sshd does. I'm quite new to systems with systemd replacing init, so hopefully I'm not just missing something trivial / simple. The BeagleBone Black in question is running Angstrom Linux and is using the opkg package manager. OpenSSH was installed with opkg install openssh. When I run systemctl enable sshd#.service, I get the following message:
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
The version I have installed is OpenSSH_6.0p1, OpenSSL 1.0.1e 11 Feb 2013
Apparently systemd has both an sshd.service unit and an sshd.socket unit, that are intended to be used mutually exclusively of each other. The sshd daemon should be started and connected automatically by systemd every time an outside process connects to port 22.
I have a daemon process, set up using launchd on Mac. The daemon is running as root. The following line does not launch my UI application -
system("launchctl start com.project.myproj");
But if I go to the terminal and run the same command -> launchctl start com.project.myproj. It launches my application. My question is am i doing something wrong or is system not behaving correctly ?
The problem is that launch daemons started by the system don't have access to Aqua, so your daemon process can't access the desktop environment.
Apple's Technical Note TN2083: Daemons and Agents describes some of this. (See this section on launchd agents.)
Someone asked a similar question about accessing the Aqua environment from an SSH connection.
I'm guessing you need to re-architect your application a bit:
Create a launch agent that runs in every user's Aqua session.
Have the agent connect to your root daemon, or have the root daemon look for an instance of the launch agent.
When signaled by the root daemon, have the launch agent launch the graphical part of the application.