Systemd vs Init Cheatsheet for Linux
Systemd is the new init framework, beginning with Fedora and presently embraced in numerous circulations like RedHat, Suse, and Centos. All things considered, the vast majority of us have been utilizing conventional SysV init scripts typically living in/and so on/rc.d/init.d/. These contents conjure a daemon parallel which will then, at that point, fork a foundation cycle. Despite the fact that shell scripts are entirely adaptable, undertakings like administering processes and parallelized execution requesting are challenging to carry out. With the presentation of systemd’s recent fad daemons, it is more straightforward to oversee and control them at runtime and it works on their execution.
The systemctl order is an awesome drive by the systemd group. It shows more point-by-point blunder messages and furthermore runtime mistakes of administrations including fire up blunders. systemd has presented another term called cgroups (control gatherings) which is essentially gatherings of interaction that can be sorted out in order. With the first init framework, figuring out which cycle does what and who it has a place with turns out to be progressively troublesome. With systemd, when cycles generate different cycles these kids are naturally made individuals from the guardians cgroup subsequently staying away from disarrays about legacy.
Service-Related Commands :
Runlevels commands:
в чем разница автозапуска /etc/init.d и /etc/systemd/system
нужное приложение обоими вариантами можно добавить и запустить.
а в чем отличие этих вариантов?
Разница в системе инициализации. Если у тебя systemd, то нужно использовать второй вариант.
У тебя че гента? Если гента то лучше удалить systemd и оставить init
Dumppper001 ★ ( 17.09.21 08:47:57 MSK )
Последнее исправление: Dumppper001 17.09.21 08:48:06 MSK (всего исправлений: 1)
а почему нужно? И второй вариант это systemd или что?
вот у меня такой скрипт работает https://gist.github.com/jdupl/dafdd0925d4a43c81d6d и как его перенести в /etc/systemd/system
Иди и читай про systemd, что за вопросы. На форуме за тебя твою работу делать не будут.
Не надо никуда переносить, всё же работает. Совместимость с /etc/init.d никто вроде удалять не собирался.
Посмотрел по диагонали. Какой ужас. Функция обновления не должна выполнятся системой инициализации. Принцип разделения ответственности.
Да. systemd — мейнстрим. Если не хочешь остаться на обочине, нужно изучать актуальные технологии.
Это не технология. И изучать там нечего.
Не нужно рыться в помойке.
А скрипты важных сервисов у меня в /usr/local/etc/rc.d вообще, никаких systemd там разумеется нет, впрочем как и sysv init.
firkax ★★★★ ( 17.09.21 11:19:39 MSK )
Последнее исправление: firkax 17.09.21 11:21:14 MSK (всего исправлений: 1)
Да. systemd — мейнстрим. Если не хочешь остаться на обочине
Именно, все равно придется когда то, так чего сопротивляться?
Так чего тогда сопротивляемся, если ничего не надо изучать?
Тем более правильно заметили, сложного нет там ничего
alex_sim ★★★★ ( 17.09.21 11:25:31 MSK )
Последнее исправление: alex_sim 17.09.21 11:26:50 MSK (всего исправлений: 1)
У него есть уже работающий скрипт. Ничего не сломалось. Зачем его куда-то переделывать? Ну, если нет никаких других интересных дел, можно и заняться настройками ради настроек.
Посмотрел по диагонали. Какой ужас. Функция обновления не должна выполнятся системой инициализации. Принцип разделения ответственности.
Она и не выполняется системой инициализации. Система инициализации вызывает этот скрипт с start|stop. А update делается когда скрипт вызывается с параметром update — вручную. Это просто скрипт технического сопровождения minecraft сервера, с интерфейсом к sysvinit в том числе, но имеющий и другие функции.
Его ответственность — обёртка взаимодействия с интерактивным джава-блобом в консольную команду. И всё с ним хорошо.
Если очень хочется, можешь написать для systemd заглушку, которая будет вызывать этот скрипт с start и stop параметром. Но вообще такая заглушка там и так есть, для всех скриптов сразу.
Команды `systemctl start minecraft` и `systemctl stop minecraft` работают же?
firkax ★★★★ ( 17.09.21 12:19:43 MSK )
Последнее исправление: firkax 17.09.21 12:20:53 MSK (всего исправлений: 1)
А update делается когда скрипт вызывается с параметром update — вручную.
Я это и имею в виду. В один скрипт намешано. Должен быть отдельный скрипт для обновления. Если ему нужно остановить сервис, то он идёт на поклон к системе инициализации.
Хейтите sd за монолитизм в пику юниксвейности, а сами тем же самым занялись.
Хейтите sd за монолитизм в пику юниксвейности, а сами тем же самым занялись.
Я нигде не хейтил монолитизм, и вообще в религиозных спорах не участвовал. systemd просто весь кривой — ибо его писали странные люди, вот и все претензии.
Раскидывать управление монолитом (каковым является minecraft server) по куче разных мест — это как раз плохо. Что-нить исправишь в одном месте, про другое забудешь. А так всё в одном файле который целиком и обновляется.
Осиливать, может и не надо, но разобраться стоит. Это хороший повод.
У тебя че гента? Если гента то лучше удалить systemd и оставить init
Init vs Systemd: What is an init daemon?
As a developer, I mostly work on Linux/Unix-like operating systems such as Ubuntu. Having used such operating systems for a few years now, I feel comfortable enough to say that I am familiar with them, but there are still many things that I still don’t understand. In this article, I would like to explore the difference between Init and Systemd. I remember during my System Administrator Devops internship, I had to perform some operations on some background service. At this point, I still had no idea what services were. I had to use commands like:
But why are there two commands that do exactly the same thing? Sadly, this question never crossed my mind. I was happy as long as the commands worked. That is, until I started working on Fedora CoreOS for Kubernetes and this happened:
$ sudo service kubelet sudo: service: command not found service is not a command?! After looking for an answer on Google, I found that the command was specific to certain Linux distributions and the solution was to use:
What!? A third command to manage services? Yup. In fact, some Linux distributions (distros) have their own command to manage services but I’m not going to go into that. In this article, I will only to talk about the init daemons Init and Systemd that use the commands service and systemctl respectively. But first, we need to understand what an init daemon is.
What is an Init Daemon?
The init daemon is the first process executed by the Linux Kernel and its process ID (PID) is always 1. Its purpose is to initialize, manage and track system services and daemons. In other words, the init daemon is the parent of all processes on the system.
What is Init?
Init (also known as System V init, or SysVinit) is an init daemon, created in the 1980s, that defines six run-levels (system states) and maps all system services to these run-levels. This allows all services (defined as scripts) to be started in a pre-defined sequence. The next script is executed only if the current script in the sequence is executed or timed out if it gets stucked. In addition to unexpected wait during execution timeouts, starting services serially makes the system initialization process inefficient and relatively slow. To create a service, you will need to write a script and store it in /etc/init.d directory. You would write a service script /etc/init.d/myService that looks something like this:
#!/bin/bash # chkconfig: 2345 20 80 # description: Description comes here. # Source function library. . /etc/init.d/functions start() < # TODO: code to start app comes here >stop() < # TODO: code to stop app comes here >case "$1" in start) start ;; stop) stop ;; restart) stop start ;; status) # TODO: code to check status of app comes here ;; *) echo "Usage: $0 " esac exit 0 You can read about chkconfig in the man page. Essentially, it defines in which run-level your service should be run. Once you have your script, you can use the service command to start, stop, and restart your service.
What is Systemd?
Systemd (system daemon) is an init daemon used by modern systems and starts system services in parallel which remove unnecessary delays and speeds up the initialization process. What do I mean by parallel? Systemd uses Unit Dependencies to define whether a service wants/requires other services to run successfully, and Unit Order to define whether a service needs other services to be started before/after it. To create a service, you will need to write a .service file stored in the /etc/systemd/system directory. You would write a file /etc/systemd/system/myService.service that looks something like this:
[Unit] Description=Some Description Requires=syslog.target After=syslog.target [Service] ExecStart=/usr/sbin/ ExecStop=/usr/sbin/ [Install] WantedBy=multi-user.target I will discuss more about how to create a service with Systemd in another article. Once you have your service file, you can start, stop and restart your service using the systemctl command.
Conclusion
Init and Systemd are both init daemons but it is better to use the latter since it is commonly used in recent Linux Distros. Init uses service whereas Systemd uses systemctl to manage Linux services. 🐢
References
- Creating a Linux service with systemd
- How to Use Systemctl to manage Systemd Services and Units
- The Story Behind ‘init’ and ‘systemd’
- Understanding and Using Systemd
- Init vs systemd
- Differences between SysVinit, Upstart and Systemd
debian 9 init.d and systemd [duplicate]
By default in Debian 9 systemd is the default. But I still see a lot of things under /etc/init.d directory. Does that mean I still can put things there to start up? Which directory (systemd or init.d) will be executed first?
The scripts in init.d will only be executed if there is no systemd-specific until file for that service.
so: all systemd service will be executed first; then init.d service which are not started from systemd, right? In another word, init.d still work fine in Debian 9, right?
The ordering will be a lot more complicated than that. init.d will work fine, but I would advise against using it.
ok. Some important packages I installed (nis, nfs) seem still putting service files under init.d instead of systemd.
1 Answer 1
When systemd starts up, or when systemctl daemon-reload is run, systemd runs a systemd-sysv-generator program, which will make a list of /etc/init.d scripts and generate corresponding .service units for them unless a systemd-native .service unit already exists for them.
The generator will interpret any LSB header blocks in init.d scripts. They look like this:
### BEGIN INIT INFO # Provides: apache2 # Required-Start: $local_fs $remote_fs $network $syslog $named # Required-Stop: $local_fs $remote_fs $network $syslog $named # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # X-Interactive: true # Short-Description: Apache2 web server # Description: Start the web server # This script will start the apache2 web server. ### END INIT INFO Any described dependencies (here $local_fs $remote_fs $network $syslog $named ) will be translated into corresponding systemd dependencies. Because there is not always a simple one-to-one mapping between init.d scripts and systemd services, some LSB dependencies like $remote_fs , $network , $named , $portmap and $time are specially mapped into corresponding systemd .target units by the generator.
The auto-generated wrapper services will simply run the corresponding init.d script. All the wrapper scripts are ordered to run after systemd basic.target , as soon as their dependencies allow. This makes the LSB headers rather important: if you’re relying on the generator mechanism and your list of dependencies is incomplete, systemd is quite likely to attempt running your init.d script too soon, before the things it depends on are ready.
It’s also possible that some packaged service has just one init.d script, but two or more systemd service files (think about NFS services for example). In such cases, the package will not rely on the generator, but instead will provide both the init.d script and the service files — with non-overlapping names. The package will also provide a symbolic link at /lib/systemd/system/.service , pointing to /dev/null . This makes systemd treat the service autogenerated from the init script as permanently masked, and the native unit files will handle the service process(es) instead.