Changes

From SME Server
Jump to navigationJump to search

SME10 serviceControl (view source)

Revision as of 20:07, 3 December 2019

12,201 bytes added ,  20:07, 3 December 2019
initial work
Line 1: Line 1:  +
=== Previous version boot process and service control ===
 +
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.
 +
 +
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.
 +
* /sbin/e-smith/service
 +
<syntaxhighlight lang="bash">
 +
#! /bin/sh
 +
 +
runlevel=$(runlevel | cut -d" " -f2)
 +
 +
if [ "$runlevel" = "4" ]
 +
then
 +
    if ls /etc/rc7.d/S??$1 >/dev/null 2>/dev/null
 +
    then
 +
      script=$(ls /etc/rc7.d/S??$1 | head -1)
 +
      exec $script $2
 +
    fi
 +
 +
    echo "'$1' is not a valid service name" 1>&2
 +
    exit 1
 +
else
 +
    exec /sbin/service "$@"
 +
fi
 +
 +
</syntaxhighlight>
 +
 +
=== Current SME10 alpha boot process and service control ===
 +
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/.
 +
 +
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''.
 +
 +
a new /sbin/e-smith/service<syntaxhighlight lang="bash" line="1">
 +
#! /bin/sh
 +
# prevent initscript to use systemctl
 +
export SYSTEMCTL_SKIP_REDIRECT=1
 +
. /etc/rc.d/init.d/functions
 +
 +
# what is our current runlevel
 +
runlevel=$(systemctl get-default)
 +
SERVICE=$1
 +
USAGE="Usage: service SERVICENAME [ACTION]"
 +
 +
#if no servicename is provided return usage
 +
if [[ "${SERVICE}" == "" ]]
 +
then
 +
  echo ${USAGE} >&2
 +
  exit
 +
fi
 +
 +
if [ "$runlevel" = "multi-user.target" ]
 +
then
 +
    if ls /etc/rc7.d/S??$1 >/dev/null 2>/dev/null
 +
    then
 +
      script=$(ls /etc/rc7.d/S??$1 | head -1)
 +
      exec $script $2
 +
 +
    elif ls /usr/lib/systemd/system/${SERVICE}.service >/dev/null 2>/dev/null || ls /etc/systemd/system/${SERVICE}.service >/dev/null 2>/dev/null
 +
    then
 +
if [[ "$2" == "" ]] ; then
 +
        echo "'$1' requires an action" 1>&2
 +
        echo ${USAGE} >&2
 +
        exit
 +
        elif  [[ $2 == "status" ]] ; then
 +
        exec /bin/systemctl status -n0 ${SERVICE}
 +
        exit
 +
        elif [[ $2 == "start" ]] ; then
 +
        echo -n  "Starting ${SERVICE}" 2>/dev/null
 +
        elif [[ $2 == "stop" ]] ; then
 +
        echo -n  "Stopping ${SERVICE}" 2>/dev/null
 +
        elif [[ $2 == "restart" ]] ; then
 +
        echo -n  "Restarting ${SERVICE}" 2>/dev/null
 +
        else
 +
        echo -n  "Sending $2 signal to ${SERVICE}" 2>/dev/null
 +
        fi
 +
        /bin/systemctl $2 ${SERVICE}.service> /dev/null
 +
        if [ $? -ne 0 ]; then
 +
        echo_failure
 +
        else
 +
        echo_success
 +
        fi
 +
        echo
 +
        exit
 +
    fi
 +
 +
    echo "'$1' is not a valid service name" 1>&2
 +
    exit 1
 +
else
 +
    exec /sbin/service "$@"
 +
fi
 +
 +
</syntaxhighlight>
 +
 +
And the current controlService perl function from /usr/share/perl5/vendor_perl/esmith/util.pm<syntaxhighlight lang="perl" line="1">
 +
=pod
 +
 +
=head1 SERVICE MANAGEMENT UTILITIES
 +
 +
=head2 serviceControl()
 +
 +
Manage services - stop/start/restart/reload/graceful
 +
 +
Returns 1 for success, 0 if something went wrong, fatal exception on bad
 +
arguments.
 +
 +
    serviceControl(
 +
        NAME=>serviceName,
 +
        ACTION=>start|stop|restart|reload|graceful
 +
        [ BACKGROUND=>true|false (default is false) ]
 +
    );
 +
 +
EXAMPLE:
 +
 +
    serviceControl( NAME=>'httpd-e-smith', ACTION=>'reload' );
 +
 +
NOTES:
 +
 +
The BACKGROUND parameter is optional and can be set to true if
 +
start/stop/restart/etc. is to be done in the background (with
 +
backgroundCommand()) rather than synchronously.
 +
 +
CONVENTIONS:
 +
 +
This command is the supported method for action scripts, blade handlers, etc.,
 +
to start/stop/restart their services. Currently this is done via the rc7
 +
symlinks, but this may change one day. Using this function gives us one
 +
location to change this behaviour if desired, instead of hunting all over
 +
every scrap of code. Please use it.
 +
 +
=cut
 +
 +
sub serviceControl
 +
{
 +
    my %params = @_;
 +
 +
    my $serviceName = $params{NAME};
 +
    unless ( defined $serviceName )
 +
    {
 +
        die "serviceControl: NAME must be specified";
 +
    }
 +
 +
    my $serviceAction = $params{ACTION};
 +
    unless (defined $serviceAction)
 +
    {
 +
        die "serviceControl: ACTION must be specified";
 +
    }
 +
 +
    if ( $serviceAction =~ /^(start|stop|restart|reload|graceful|adjust|svdisable)$/ )
 +
    {
 +
        my ($startScript) = glob("/etc/rc.d/rc7.d/S*$serviceName") ||'' ;
 +
        my ($systemdScript) = "/usr/lib/systemd/system/$serviceName.service" ||'';
 +
 +
        unless ( -e $startScript or -e $systemdScript)
 +
        {
 +
            warn "serviceControl: startScript not found "
 +
              . "for service $serviceName\n";
 +
            return 0;
 +
        }
 +
 +
        if (-e $systemdScript and ! -e $startScript){
 +
            if ($serviceAction =~/^(start|stop|restart|reload)$/) {
 +
                system('/usr/bin/systemctl',"$serviceAction","$serviceName.service") == '0'
 +
                ||    warn "serviceControl: Couldn't " .
 +
                "system( /usr/bin/systemctl $serviceAction $serviceName.service): $!\n";
 +
            }
 +
            else {
 +
                die "serviceControl: systemd doesn't know : systemctl $serviceAction $serviceName.service";
 +
            }
 +
        }
 +
 +
        elsif (-e $startScript) {
 +
            my  $background = $params{'BACKGROUND'} || 'false';
 +
 +
            if ( $background eq 'true' )
 +
            {
 +
            backgroundCommand( 0, $startScript, $serviceAction );
 +
            }
 +
            elsif ( $background eq 'false' )
 +
            {
 +
                unless ( system( $startScript, $serviceAction ) == 0 )
 +
                {
 +
                warn "serviceControl: "
 +
                  . "Couldn't system($startScript, $serviceAction): $!\n";
 +
                return 0;
 +
                }
 +
          }
 +
          else
 +
          {
 +
            die "serviceControl: Unsupported BACKGROUND=>$background";
 +
          }
 +
        }
 +
    }
 +
    else
 +
    {
 +
        die "serviceControl: Unknown serviceAction $serviceAction";
 +
    }
 +
    return 1;
 +
}
 +
 +
</syntaxhighlight>
 +
 +
=== Systemd Integration possibilities ===
 +
this is intended to make an open discussion about possibilities, in order to choose the best SME approach to systemd.
 +
 +
Issue to solve :
 +
* SME vs upstream
 +
* make unit files aware of service status in e-smith db configuration
 +
* have our services boot in the right sequence
 +
* journald vs rsyslogd
 +
* plain file log vs  special file format
 +
* enabling /disabling /masking services
 +
 +
'''Table 1.         Load path when running in system mode (<code>--system</code>).'''      <ref>https://www.freedesktop.org/software/systemd/man/systemd.unit.html</ref>
 +
{| class="wikitable"
 +
!Path
 +
!Description
 +
|-
 +
|<code>/etc/systemd/system.control</code>
 +
| rowspan="2" |Persistent and transient configuration created using the dbus API
 +
|-
 +
|<code>/run/systemd/system.control</code>
 +
|-
 +
|<code>/run/systemd/transient</code>
 +
|Dynamic configuration for transient units
 +
|-
 +
|<code>/run/systemd/generator.early</code>
 +
|Generated units with high priority (see ''<code>early-dir</code>'' in systemd.generator(7))
 +
|-
 +
|<code>/etc/systemd/system</code>
 +
|System units created by the administrator
 +
|-
 +
|<code>/run/systemd/system</code>
 +
|Runtime units
 +
|-
 +
|<code>/run/systemd/generator</code>
 +
|Generated units with medium priority (see ''<code>normal-dir</code>'' in systemd.generator(7))
 +
|-
 +
|<code>/usr/local/lib/systemd/system</code>
 +
|System units installed by the administrator
 +
|-
 +
|<code>/usr/lib/systemd/system</code>
 +
|System units installed by the distribution package manager
 +
|-
 +
|<code>/run/systemd/generator.late</code>
 +
|Generated units with low priority (see ''<code>late-dir</code>'' in systemd.generator(7))
 +
|}
 +
 +
==== 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.
 +
* 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.
 +
systemctl daemon-reload has be run after each modification of a unit. Hence generated files by generators will be erase and generators rerun. <ref>https://www.freedesktop.org/software/systemd/man/systemctl.html#daemon-reload</ref>
 +
 +
==== Overide upstream vendor preset : templated unit files or not ? where ? ====
 +
Thinking of the example of a service unit provided by upstream vendor. Should we simply create a template and expand it over the unit.service in /lib/systemd/system/ or offer a different way to override upstream vendor settings ? Further more should we template our file to point to /lib/ or to /etc/. In other words, should we fight with admin space trying to overwrite changes in its dedicated space or should we fight with upstream vendors and overwrite their files or find a way to override them.
 +
 +
hence the questions
 +
* where: /etc or /lib/
 +
* How : template or not
 +
* How: overwrite or selective overriding
 +
 +
===== unit files created in /etc/systemd/system/ or in /lib/systemd/system/ =====
 +
as a vendor we should work in /lib/systemd/system/, but as an admin helper we might want to play in /etc/systemd/system/ and rather offer a way to admin to use our template-custom or config db.
 +
 +
==== template or not ====
 +
the first easy way to think to override ones service could be to simply template the file  /lib/systemd/system/servicename.service and expand it every time a reconfiguration or a boot occurs.
 +
 +
Going futher we could ensure the stability of the system by making this in /etc/systemd/system/servicename.service
 +
 +
===== unitname.d/file.conf versus overwrite uniname.service =====
 +
dot d folder can be created both int etc and lib from readings and inspection in a few systems.
 +
 +
There are two methods of overriding vendor settings in      unit files: copying the unit file from      <code>/usr/lib/systemd/system</code> to      <code>/etc/systemd/system</code> and modifying the      chosen settings. Alternatively, one can create a directory named      <code>''<code>unit</code>''.d/</code> within      <code>/etc/systemd/system</code> and place a drop-in      file <code>''<code>name</code>''.conf</code>      there that only changes the specific settings one is interested      in. Note that multiple such drop-in files are read if      present, processed in lexicographic order of their filename.
 +
 +
The advantage of the first method is that one easily      overrides the complete unit, the vendor unit is not parsed at      all anymore. It has the disadvantage that improvements to the      unit file by the vendor are not automatically incorporated on      updates.
 +
 +
The advantage of the second method is that one only      overrides the settings one specifically wants, where updates to      the unit by the vendor automatically apply. This has the      disadvantage that some future updates by the vendor might be      incompatible with the local changes. <ref>https://www.freedesktop.org/software/systemd/man/systemd.unit.html</ref>
 +
 +
==== uninstalling /masking unwanted/conflicting services: example of firewalld. ====
 +
we can plan to uninstall firewalld for example, but some packages will reinstall as a requirement. It might even be started, which could conflict with masq.
 +
 +
=== References ===
 +
<references />
 
[[Category:SME10-Development]]
 
[[Category:SME10-Development]]
Unnilennium
Super Admin, Wiki & Docs Team, Bureaucrats, Interface administrators, Administrators
3,239

edits

Retrieved from "https://wiki.koozali.org/Special:MobileDiff/38190"

Navigation menu