How to Autorun Application at the Start up in Linux
Introduction
This article describes how to automatically start an application during or after boot of an Apalis, Colibri and Verdin Computer on Modules running Embedded Linux.
Torizon OS
On Torizon OS, the applications are packaged in containers. The containers are run by the container engine, which is Docker in our case.
Docker is already set to autorun, and to start your applications on boot in Torizon OS you must describe what containers to use and how to bring them up. Please have a look at our content about the steps to automatically start a container with Torizon OS in Run and Manage Docker Containers on Torizon.
Reference Images for Yocto Project
For our Reference Images for Yocto Project, you can follow any of the topics described below in order to attend to your project or use-case needs.
Systemd
Starting with V2.x of our Linux BSP we use systemd as our init and service manager.
Systemd is a system and service manager for Linux, also capable of replacing the traditional SysV init system. You can read its manual here.
A unit configuration is a file which name ends in .service, and it encodes information about a process controlled and supervised by systemd. Service files can be found in /etc/systemd/system/ and, for distribution provided ones in /lib/systemd/system/.
You can enable, disable, start, stop and check services status by using the systemctl command.
The common configuration items are configured in the generic [Unit] and [Install] sections.
The service specific configuration options are configured in the [Service] section.
Service files must include a [Service] section, which carries information about the service and the process it supervises.
For more information possible options of a [Service] section refer to the documentation.
Procedure
Create a unit configuration file ending in .service
Copy the unit configuration file to /etc/systemd/system and use the systemctl tool for enabling and starting the service.
Using the systemctl command
Based on the SystemD documentation, you need to reload the systemd configuration after the addition or change on any unit files:
# systemctl --system daemon-reload
To check a service status, or to start and stop a service, which is valid until next reboot, you can use the following commands:
# systemctl status <service_name>.service
# systemctl start <service_name>.service
# systemctl stop <service_name>.service
To add a service to or remove it from the list of services to be started at boot.
This neither starts or stops the service but takes only effect during the next boot
# systemctl enable <service_name>.service
# systemctl disable <service_name>.service
Here is an example of an unit configuration file to automatically execute the (hypothetical) mydatalogger application at start up:
[Unit]
Description=mydatalogger service, collects and logs data in the background
After=multi-user.target
[Service]
Type=simple
ExecStart=/usr/bin/mydatalogger
[Install]
WantedBy=multi-user.target
Shells
/etc/profile
Each time a login shell is spawned, the script /etc/profile plus all scripts in /etc/profile.d are executed.
This is done for logins over a serial console, over an ssh connection and also for logins in the display manager to a graphical desktop.
/etc/profile is sourced upon login: it sets up the environment upon login and application-specific settings by sourcing any readable file in /etc/profile.d/.
Using /etc/profile is well suited to set the environment or to do some small tasks.
Note that these scripts must return control in order to continue with the login.
Remove the file in /etc/profile.d or the additions to /etc/profile in order to undo the automatic execution.
Procedure
To load a Shell Script at each login, you just need to add a script file in /etc/profile.d/.
Remembering that the Shell Script must have the *.sh extension.
Below is an example of a script file for deleting backup entries:
#!/bin/sh
rm /home/root/*~
Graphical
Weston Desktop
Since Toradex Linux BSP version 5, Weston/Wayland graphic compositor has been used instead of X11.
Please be aware that Wayland is the Protocol, Weston is the Graphical Compositor which implements the Wayland protocol. You can read more about it at Wayland page.
Any graphical application developed for X11 should work as well, as the Weston compositor is configured to operate with the XWayleand compatibility mode, which allows X11 Clients.
That said, for you to create a graphical application that will automatically start with the system boot, this application must start after Weston service.
An example for a wayland graphical application to be automatically executed on boot is presented below.
[Unit]
Description=Start a wayland application
After=weston@root.service
Requires=weston@root.service
[Service]
Restart=on-failure
Type=forking
ExecStart=/usr/bin/wayland-app-launch.sh
RestartSec=1
[Install]
WantedBy=multi-user.target
As you can see, that service calls a script to be executed. That's because it's necessary to check if the XDG_RUNTIME_DIR environment variable has been set, and if not, we must set it.
Weston will use XDG_RUNTIME_DIR for Window Context.
It's also recommended to export the DISPLAY variable accordingly as well. See below:
#!/bin/sh
if test -z "$XDG_RUNTIME_DIR"; then
export XDG_RUNTIME_DIR=/run/user/`id -u`
if ! test -d "$XDG_RUNTIME_DIR"; then
mkdir --parents $XDG_RUNTIME_DIR
chmod 0700 $XDG_RUNTIME_DIR
fi
fi
# wait for weston
while [ ! -e $XDG_RUNTIME_DIR/wayland-0 ] ; do sleep 0.1; done
sleep 1
export DISPLAY=:0.0
/path/to/the/application &
With both the service and the script, your Wayland application will be automatically executed on boot.
Yocto Project/OpenEmbedded
We prepared scripts to autorun your application in Wayland/Weston on startup directly from a Yocto Project/OpenEmbedded build. It is called wayland-app-launch and also how we autorun Qt Demos on the Multimedia Reference Image. Check out the given links, which contain examples of how you can integrate this into OE.