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.