Functional scope
Functional scope
An overview of the functionality provided by the Node Startup Controller
Introduction
The Node Startup Controller (NSC) was introduced into the lifecycle package for
GENIVI in order to handle some startup and shutdown functionality. It essentially
"extends" systemd to implement some IVI requirements that are not done by systemd
itself because they are not generally applicable for all Linux systems (as
determined through discussion with the systemd community). However, similar
functionality might be desired in non-automotive systems so we hope this can be
useful and/or develop into something shared across domains.
The main areas of responsibility for the NSC are:
Last User Context (LUC) Management
Legacy Application Management
Target Startup Monitoring
Last User Context (LUC) management
The Last User Context (LUC) management holds information about what applications
the user was using in the last lifecycle, in order to allow the same applications
to be restored automatically, or prioritized over other applications the next
time the system boots up. Applications are stored in the LUC groups whose start
order is defined at build time. The choice is fully flexible, but for a typical
Automotive IVI system, these groups could be:
Audible
Applications that are current audible sources within the Head Unit (e.g.
radio or CD player).
Foreground
Applications that are currently in the focus of the HMI (e.g., navigation
or web browser).
Background
Applications that run in the background.
The LUC allows multiple applications to be registered for each LUC type at the
same time. A registration with the LUC consists of two parameters:
A systemd unit filename (e.g. navigation.service),
The LUC type, which is a number that represents the group, e.g. 0 for audible,
1 for foreground, 2 for background.
The LUC management simply stores the systemd unit name (e.g.
navigation.service) for each LUC-managed application and communicates with
systemd to start up these applications shortly after boot. Systemd D-Bus
interfaces are used instead of simply a stored systemd target file on disk.
This is to allow the behavior to be flexible according to system policy and
because the behavior might also be dynamic as described in the next section.
Units in a start-up group are all started in parallel. The order in which each
group is started can be configured at build-time.
In order to reduce the amount of communication with the LUC management, multiple
applications can be registered and deregistered with a single D-Bus call.
Legacy application management
In this context "Legacy applications" means applications that do provide a
systemd unit file but are otherwise unaware of, or do not make use of other
GENIVI/Lifecycle components. This means that the applications will not actively
register themselves as a shutdown consumer in the Node State Manager (NSM).
(That is the normal way for the NSM to know what applications are active and can
be controlled in order to sleep/shutdown.) To solve the "legacy applications"
problem, the NSC provides a mechanism to separately register such applications
as shutdown consumers.
To solve this problem the Node Startup Controller provides a mechanism to register
shutdown consumers for individual legacy applications. This works as follows:
the Node Startup Controller provides an internal D-Bus interface for registering
a shutdown consumer for a given unit filename,
the Node Startup Controller provides a helper executable that takes a unit
filename and calls the above D-Bus method to register a shutdown consumer for
this unit file, an ExecStartPost command is added the unit
files of legacy applications that calls the helper script or binary.
Whenever the NSM decides to perform a shutdown it will ask the shutdown consumers
to shut down in reverse order of their creation. To the NSM it does not matter
whether or not the consumers are registered by applications themselves or by the
Node Startup Controller.
There is some other behavior also during shut-down which should be mentioned
here fore completeness, although it is controlled by the Node State Manager (NSM)
as opposed to NSC. Specifically it is the requirement to implement "cancelled
shutdown" which is not typically present in non-IVI Linux systems.
Target startup monitoring
The Node Startup Controller is responsible to set certain NSM states when certain
systemd targets (e.g. focussed.target or
lazy.target) have been started within or outside the
Node Startup Controller. For this, it needs to monitor systemd for unit start-up
events.
As of systemd 183, this is possible through systemd's JobRemoved signal.
The Node Startup Controller
sets the NSM state to BASE_RUNNING during initialization,
subscribes to systemd in order to receive signals from systemd,
evaluates the received JobRemoved signals by filtering out the signals that do
not belong to target start-up events setting the NSM state to
LUC_RUNNING when focussed.target
has been started,
FULLY_RUNNING when unfocussed.target
has been started,
FULLY_OPERATIONAL when lazy.target
has been started.