Skip to main content
Version: BSP 6.x.y

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.

info

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:

mydatalogger.service
[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:

remove_backup.sh
#!/bin/sh
rm /home/root/*~

Graphical​

Weston Desktop​

The X11 was the display server used until our BSP 3.0.

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.

wayland-app-launch.service
[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:

wayland-app-launch.sh
#!/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.

X11 Desktop​

You can start applications automatically when you login into your Window Manager or Desktop Environment.

With the angstrom-lxde-image you'll get the following options. Other desktop environments provide similar means.

The lxsession session manager can start applications when the graphical environment is started.

This can be achieved in two ways:

  1. A lxsession specific way, in which the entries in the files /etc/xdg/lxsession/LXDE/autostart and ~/.config/lxsession/LXDE/autostart are parsed.

  2. A generic way which many session managers support. Files in the folders /etc/xdg/autostart/ and ~/.config/autostart/ ending with .desktop get parsed and, if applicable, the application described therein is started.

You can check more information in the LXSession documentation (archived).

LXSession Autostart File​

To use the 1st option, you will need to edit /etc/xdg/lxsession/LXDE/autostart or ~/.config/lxsession/LXDE/autostart.

Add the application or command-line you want to be executed to a new line in the file.

If you want that your application be restarted if it gets terminated abnormally, precede the application name with a @. Like for example the lxterminal, with @lxterminal at /etc/xdg/lxsession/LXDE/autostart:

/etc/xdg/lxsession/LXDE/autostart
@lxpanel --profile LXDE
@pcmanfm --desktop --profile LXDE
@xscreensaver -no-splash
@lxterminal

Note that this file is not a shell script and therefore shell acrobatics like redirections and pipes are not allowed.

If required this can done by spawning a custom shell script, which in turn can support the full shell feature set.

.desktop Files​

Basically, to have a service or application to start with this approach, the steps are to create a .desktop file and add it to autostart.

You can check more information about this in the .desktop file documentation.

info

In /usr/share/applications/ there is already a number of .desktop files which can be copied into the autostart folder.

For example, if you want to execute lxterminal automatically at startup, you can do the following:

  1. Create a terminal.desktop in /etc/xdg/autostart/ . Add some key entries like:
  • [Desktop Entry] - Must be the first line of every desktop file and is the section header to identify the block of key value pairs associated with the desktop. Necessary for the desktop to recognize the file correctly.
  • Name of the application. (The name of the Desktop Entry group - should be unique on the system).
  • Type of the application. (Possible values are "Application", "Link" or "Directory").
  • Exec filename of the application plus optionally arguments.
  • Terminal (Describes whether the application should run in a terminal).

An example of a .desktop file content with the entries should be as follows:

my_sample.desktop
[Desktop Entry]
Name=LXTerminal
Type=Application
Exec=lxterminal
Terminal=false
  1. After editing, save the .desktop.
info

A graphical file manager will list .desktop files not with their file name but rather with the value of the key "Name". E.g. in the example above "LXTerminal".

To disable the automatic start of an application, just either remove the respective *.desktop file from /etc/xdg/autostart/ and/or .config/autostart/, or add the key NotShowIn=LXDE; to the desktop file.

Alternatively use the graphical front end 'LXDE Menu'/Preferences/'Desktop Session Settings' and untik the 'Enabled' checkbox.

X11 with One User Application​

If your use-case requires to start X11, probably it will also require to start some configuration tasks like keyboard mapping, touch screen calibration and then start the one and only user application. In this case, you can adopt a scheme like the one used in angstrom-qt5-x11-image and qt4e-demo-image.

Script Started by Systemd​

The qt4e-demo-image and angstrom-qt5-x11-image (prior to 2.8b2) use a systemd service and a home brew script. The script starts the X-server followed by the user application. Integrating any setup tasks between the start of X11 and the start of the user application into the script produces a bunch of issues as this sometimes stops the X-server and so on.

However for a simple system that might be enough.

To start your X11 application instead of the demo application change the script accordingly.

Using nodm, xinit, and a Custom Script​

The angstrom-qt5-x11-image (starting with 2.8b2) uses the simple display manager nodm from OpenEmbedded to start X11. This uses the configuration data in /etc/X11, e.g. Xsession.d, e.g. to start the touch calibrator. As the last step it searches for a script x-window-manager and sources that one.

To start your X11 application override the following two variables in the x-window-simple-app recipe to set the initial working directory and to specify the application:

INITIAL_PATH ?= "/usr/share/qtsmarthome-1.0"
X_APPLICATION ?= "${INITIAL_PATH}/smarthome"


Send Feedback!