I need one process run before log in to system. How to run it like services? how do I make services in Linux?
In Ubuntu and Fedora? The service is customized tomcat
initstartup
I need one process run before log in to system. How to run it like services? how do I make services in Linux?
In Ubuntu and Fedora? The service is customized tomcat
On Ubuntu 18.04, [...]
I heard there are several ways of managing services: system V init, systemd, upstart, .... Which one am I using?
You're using systemd, that's the init that's shipped on Ubuntu 18.04. (Also on Ubuntu 16.04, on Fedora, on openSUSE, on Arch Linux, on RHEL 7, on CentOS 7, on CoreOS, and it's also the default on Debian 9.)
One good way to confirm that you're running systemd is to run the command systemctl
. If it's available and it produces output when run, then you're running systemd.
On Ubuntu 18.04, I can start or stop some service by
sudo service cron start/stop
I can list some services by
service --status-all
Please note that the service
command shipped in some systemd distros is there mostly for backward compatibility. You should try to manage services using systemctl
instead.
For example:
$ sudo systemctl start cron
$ sudo systemctl stop cron
$ systemctl status cron
And you can find status of all units with a simple
$ systemctl
The output matches the files under
/etc/init.d/
.
That's not necessarily the case with systemctl
, since systemd native units are stored in /etc/systemd/system/
and /usr/lib/systemd/system/
.
systemd does include compatibility with old SysV init scripts (through systemd-sysv-generator, which creates a systemd native service unit calling the commands from the init script), so if you have init scripts under /etc/init.d/
, they'll most likely show up in systemd as well.
Shall I use systemd instead of init on Ubuntu?
This question is unclear.
The term init
generally refers to the first process run when the system boots, the process run with PID 1. systemd runs with PID 1, so by definition systemd is an init (and so was upstart before it, and SysV init as well.)
If you're asking "should I use systemd instead of SysV init?", well then you're already using systemd instead of SysV init, since you're on Ubuntu 18.04. (And, as pointed out above, most distributions you'd pick these days would most likely include systemd as their init.)
Now, you could be asking "should I use systemd units instead of init scripts?" and that question is more relevant, since arguably you have a choice here where both options will work.
My recommendation here is that you should manage services using systemd units, which is the native mode of operation. Creating an init script simply adds a layer of indirection (since the generator will just create a systemd unit for you anyways.) Furthermore, writing systemd units is simpler than writing init scripts, since you don't have to worry about properly daemonizing and scrubbing the environment before execution, since systemd does all that for you.
How can I make an arbitrary executable file (either ELF or shell script) become a service?
Create a systemd service unit for it.
See the examples on the man page. The simplest example shows how easy it can be to create a service unit:
[Unit]
Description=Foo
[Service]
ExecStart=/usr/sbin/foo-daemon
[Install]
WantedBy=multi-user.target
Store this unit under /etc/systemd/system/foo.service
, then reload systemd to read this unit file with:
$ sudo systemctl daemon-reload
Start the service with:
$ sudo systemctl start foo.service
And enable it during startup with:
$ sudo systemctl enable foo.service
You can check the status of the service with:
$ systemctl status foo.service
Of course, systemd can do a lot more for you to manage services, so a typical systemd unit will be longer than this one (though not necessarily that much more complex.) Browse the units shipped with Ubuntu under /usr/lib/systemd/system/*.service
to get a better picture of what's typical, of what to expect.
Do I need to explicitly daemonize the executable by
setsid
, like https://stackoverflow.com/a/19235243/156458?
No! Don't run in background, don't worry about process groups or sessions, etc. systemd takes care of all that for you. Just write your code to run in foreground and systemd will take care of the rest.
(If you have a service that runs in background, systemd can manage it, with Type=forking
, but things are much easier when just running in foreground, so just do that if you're starting a new service.)
Does any of the post below apply to me?
This one is about applications using the "Spring Boot" Java framework. Unless you're writing Java code and using that framework, it's not relevant. If you're writing Java code, try instead to just run your service in foreground instead.
The question is about upstart, the answer is about SysV init scripts. While SysV init scripts will work with systemd, it's preferable that you write systemd units directly, as mentioned above.
So, no, I'd say neither of those are relevant.
I'd recommend trying to learn more about systemd service units instead.
This site is also a great resource for that, so feel free to post more questions about it as you explore writing your own systemd units for your services.
Best Answer
To run a service without or before logging in to the system (i.e. "on boot"), you will need to create a startup script and add it to the boot sequence.
There's three parts to a service script: start, stop and restart.
The basic structure of a service script is:
Once you have tweaked the script to your liking, just place it in /etc/init.d/
And, add it to the system service startup process (on Fedora, I am not a Ubuntu user, >D):
Service will be added to the system boot up process and you will not have to manually start it up again.
Cheers!