653
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + − Basically we use SysVinit, with initscripts built to handle a specific run level rc7.d. On top of that we use Runit to handle services indexed in /services / and /var/services. + − + Line 25:
Line 25: − + − Systemd has been designed as the way to handle services upstream. Systemd will override all /etc/rc.d/init.d/ scripts and call to /usr/sbin/service.+ − We have added a first systemd unit for bootstrap console and make it a drop in replacement of Sysvinit to boot all processes linked in /etc/rc.d/rc7.d/.+ − + + + Line 337:
Line 339: − + − this is intended to make an open discussion about possibilities, in order to choose the best SME approach to systemd.+ − Issue to solve :+ − + − + Line 383:
Line 385: − + − there have been suggestions about using a generator, it is not clear how and why it would help. This approach would be more complex. and according to the doc<ref>https://www.freedesktop.org/software/systemd/man/systemd.generator.html#</ref>: +
no edit summary
=== Previous version boot process and service control ===
=== '''Versions previous to 10: boot process and service control''' ===
SysVinit is used, with initscripts built to handle a specific run level rc7.d. Over that we use Runit to handle services indexed in /services / and /var/services.
A cli wrapper for the command service /sbin/e-smith/service has been created so that only initscripts which exist in run-level 7 can be run. This ensures that the supervised service is run, if one exists, and protects against running "service httpd restart". The wrapper will also choose between a sv command for runit processes or regular call to /etc/rc.d/init.d/ scripts.
A cli wrapper for the command service /sbin/e-smith/service has been created so that only initscripts which exist in run-level 7 can be run. This ensures that the supervised service is run, if one exists, and protects against running e.g. "service httpd restart" directly. The wrapper will also choose between an sv command for runit processes or a regular call to /etc/rc.d/init.d/ scripts.
* /sbin/e-smith/service
* /sbin/e-smith/service
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
</syntaxhighlight>
</syntaxhighlight>
=== Current SME10 alpha boot process and service control ===
=== '''Version 10 on: boot process and service control''' ===
'''Current SME10 alpha boot process and service control'''
Systemd is the new Linux standard to handle services and service monitoring and is enforced upstream. Systemd will supersede all /etc/rc.d/init.d/ scripts and calls to /usr/sbin/service.
From there we could keep this way, or try to move as many process as we can to systemd. This way works, but is even more complex than it was on previous SME version. Plus we can not guarantee without further scripts that one will not be able to do a ''systemctl start httpd''.
We have added a first systemd unit to bootstrap the console and made it a drop in replacement of Sysvinit to boot all processes linked in /etc/rc.d/rc7.d/.
From there we could keep on this way, or try to move as many processes as we can to systemd. That works, but is even more complex than it was on the previous SME versions. Additionally we can not guarantee -- without further scripts -- that a ''systemctl start httpd'' would be blocked.
* new startup with console see /usr/share/perl5/vendor_perl/esmith/console/startup.pm
* new startup with console see /usr/share/perl5/vendor_perl/esmith/console/startup.pm
<syntaxhighlight lang="perl">
<syntaxhighlight lang="perl">
</syntaxhighlight>
</syntaxhighlight>
=== Systemd Integration possibilities ===
=== '''Systemd Integration: Options and possibilities''' ===
This section is intended to open up a discussion concerning options and possibilities, in order to facilitate choosing the optimal SME approach to systemd.
Issues to solve :
* SME vs upstream
* SME vs upstream
* make unit files aware of service status in e-smith db configuration
* make unit files aware of service status in e-smith db configuration
* have our services boot in the right sequence
* have our services boot in the right sequence
* journald vs rsyslogd
* journald vs rsyslogd
* plain file log vs special file format
* plain file log vs special file format
* enabling /disabling /masking services
* enabling /disabling /masking services
|}
|}
==== generators ====
==== '''Generators''' ====
There have been suggestions about using a generator, it is not clear how and why it would help. This approach would be more complex. and according to the doc<ref>https://www.freedesktop.org/software/systemd/man/systemd.generator.html#</ref>:
* Units written by generators are removed when the configuration is reloaded. That means the lifetime of the generated units is closely bound to the reload cycles of '''systemd''' itself.
* Units written by generators are removed when the configuration is reloaded. That means the lifetime of the generated units is closely bound to the reload cycles of '''systemd''' itself.
* Generators should only be used to generate unit files and symlinks to them, not any other kind of configuration. Due to the lifecycle logic mentioned above, generators are not a good fit to generate dynamic configuration for other services. If you need to generate dynamic configuration for other services, do so in normal services you order before the service in question.
* Generators should only be used to generate unit files and symlinks to them, not any other kind of configuration. Due to the lifecycle logic mentioned above, generators are not a good fit to generate dynamic configuration for other services. If you need to generate dynamic configuration for other services, do so in normal services you order before the service in question.