Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
"Daemon": A general term for processes detached from the starting terminal, so it will not write or read from it and receive signals (like " HUP") send to the terminal. Pracitcally this is done by closing stdout and -in and a double form.
---
Usually services are managed by "init", the first process (so it has the PID 1). The init implementations changed over the years:
- SysV init (from Unix V) defines " run levels" 1...6 where different services are defined to run. SysV init is still very popular. All "services" are defined as shell scripts in /etc/init.d or /etc/rc.d. Those shell scripts implement commands like "start" and "stop", so they usually have to manage the process id (e.g. "/etc/init.d/httpd start" would start Apache). The downside of it: Every software developer has to write their own shell script for their self made services. While there do exist helpers (e.g. start-stop-daemon) in can be quite redundant. Some applications have more complex init scripts, others have just implemented stop and start.
- On many Linux distributions SysV init has been replaced by "systemd". It is a huge piece of software. But basically it allows to define service files which keeps the services as subprocesses so PID management isn't required anymore. Of course systemd still supports daemons and even the previously used SysV init scripts. Additionally, the concept of run levels has been replaced by so called "targets", which are bit more flexible. The systemd units are placed in /etc/systemd/system.
I hope I could help? -
Convenience of using start/stop/restart. Also, it works with the runlevel support of daemons/scripts. When you startup, run console only, run x11, shutdown, etc there are runlevels assigned. Changing run levels automagically runs scripts. Its been a while since i played with this, but I think that is gist of it.
-
donuts236725y@Demolishun is there something like a template or builder for these it have to work each from scratch?
I have a 1-line command that starts a program with some parameters. And maybe as a different user vs root. -
@billgates I did a daemon in Python a while back. I cannot remember where I got the template, but I found it using Google.
I don't know if this is the same one I used before:
https://github.com/martinrusev/...
I would spend some time learning the runlevel ecosystem in Linux. I am really not even sure where to look for info on that. You can look in etc/init.d I think should have some runlevel scripts in there. -
@billgates If you have systemd, write a unit, so deamonizing isn't required anymore. Otherwise look at the other init scripts already on your system.
-
donuts236725y@sbiewald I don't know what I have other than RHEL7. We were on 5 before.... new servers...
-
@Demolishun It can still be used for a long time.
@billgates RHEL7 has Systemd, RHEL<=6 SysV Init. Both init systems are compatible with SysV init scripts.
Edit: RHEL 6 used upstart for init.
I want to understand Linux services better. Most of the time if I want to run a process in the background, I just use nohup and &
And put the commands in either init.d or crontab.
But lately I've seen some more complex scripts where it's called like logstash start/stop which does a free things including recording the PID somewhere?
In Linux terms it seems to be called starting a daemon. But what's the difference, benefit to all this complexity?
question