Optional Services

---

The G3 module includes a number of Linux services that may or may not be of value to your particular application use case. Reach Technology has engineered the system so these services can be enabled or disabled by using the chkconfig command.

You should disable services that are not required by your end product application to reduce memory and CPU cycle consumption. This will also reduce boot time.

Tip

To manage optional services, log in to the G3 module as root, then:

# to list available services
root@imx6dl-g3-sd:~# chkconfig

# to enable a service
root@imx6dl-g3-sd:~# chkconfig <service-name> on

# to disable a service
root@imx6dl-g3-sd:~# chkconfig <service-name> off

# to activate the selected set of services
root@imx6dl-g3-sd:~# sync
root@imx6dl-g3-sd:~# reboot

The following table lists the available optional services.

Optional Services

Service	Description
bluetooth	setup bluetooth devices
cgroups-init	setup kernel control groups
dbus-1	system software communication bus
docker.init	application service containerization1
firehol	very strong firewall with minimal rules required
lighttpd	light weight web server
mosquitto	MQTT broker
netmount	mount NFS filesystems listed in /etc/fstab2
networking	control loopback3, ethernet and wireless interfaces4
nfscommon	provides rpc.statd for NFS
ntpdate	network time synchronization (gross adjustment at boot)
ntpd	network time synchronization (continuous runtime tweaks)
nginx	reverse proxy
ppp	control dialup interfaces4
pulseaudio.sh	audio mixing server
redis-server	fast memory resident KVP database
rng-tools	random number generator tools5
rpcbind	rpc mapper for NFS
sshd	secure shell server6
user_app	controls end product (user) application7

---

Footnotes:

1

Docker containers are available but have not been tested extensively as of the writing of this document.

2

The G3 module can mount shares from NFS servers. It cannot act as an NFS server.

3

The networking service should always be enabled if the end product application requires the loopback (localhost) interface… almost always true.

4(1,2)

Wireless devices such as WiFi or BLE dongles are controlled by the networking service. Most CDMA/GSM/LTE modems are controlled be the ppp service even though they are actually wireless devices.

5

The random number generator service should be left enabled unless you can guarantee that your application does not employ networking or encryption. The only advantage to turning it off is that boot time will decrease by a few seconds.

6

You should only turn sshd off if there are no network connections into the end product that the G3 module is integrated into. See here for cautions regarding sshd.

7

See and here for information on installing the end product application and here for details on how it is launched at system boot. NOTE: the node.js package is installed but does not have a dedicated init script because it requires application-specific code. Thus Reach Technology assumes that the end product application init script, run_application, will handle starting and stopping of node.js based application components.

Boot Time Optimization

In the age of instant gratification, everyone wants to see the product UI on the screen within two seconds after pushing the power on button. Sadly, that’s not really possible. The typical substitute is to put up a splash screen as early as possible so the user knows the system is alive while it finishes booting. Depending on the complexity of your end product application and the services it requires, system boot times can vary widely. Despite the desire to have the system “online” as quickly as possible, one must always ensure that the system is always safe. In the age of ubiquitous internet connectivity, this brings some very important considerations to the table which inevitably affect boot times adversely. Here are some things to consider when optimizing your product boot time.

• The single most expensive (time-wise) service is firehol. This service sets up a strong iptables based firewall8. If you don’t have an active ethernet, WiFi or PPP network connection, you can safely disable this. Also, if you only have a local ethernet inside your product, you can safely disable this. This service is disabled by default. So any network connections to the target are wide open until you enable firehol.

• The second most expensive service is networking. The eth0 interface is set in “auto” mode by default. This means that if the wire is plugged in, the interface will be brought up (which takes 4 to 5 seconds) and then dhcpcd will attempt to get a dynamically assigned IP address as well as requisite DNS and routing configuration data. On the other hand, if the wire is not plugged in, it can take quite a while (up to 15 seconds) for the init code to punt on bringing up the interface. So, because it’s generally a very bad idea to completely disable the networking service, you absolutely should comment out the “auto eth0” line in /etc/network/interfaces file if you are not using the ethernet port.

• The ntp_date client is intended to make large corrections to the system timestamp (much larger than what ntpd is allowed to do) just once at system boot. It won’t do you any good if you don’t have some kind of network connection. It’s also not really necessary if your product is not expected to sit for long periods with the power off. The RTC is temperature compensated and should remain well within the tweak limits of ntpd for quite some time.

• Like ntpdate, ntpd is not needed if you don’t have an external network connection of some kind. However, if you are using NFS, you must always use ntpd (on both the G3 module and the server) to avoid system hangs due to clock skew.

• There are several services related to HTML content and web apps. These include lighttpd, nginx and node.js. The last one is not started unless your run_application script launches it. You can leave lighttpd off if your product UI is not based on HTML5 (i.e. you haven’t built a web UI or a RESTful API). The nginx proxy is a bit more complicated. Generally, if you have an external network and are offering web services via lighttpd or a node.js based app, or if you are using either the redis-server database or the mosquitto MQTT server and allowing external access then you should proxy those things behind nginx. The biggest reason for this is that you can do all of your web security and access logging config in nginx rather than having to do it multiple times for all those other components.

• If your product does not use audio, you can safely disable pulseaudio.sh and dbus-1.

• If your product does not use containers, you can safely disable docker.init and cgroups-init.

Warning

There are dependencies between some of the optional services. The table below elaborates the known service dependencies. If “net” is listed as a dependency, that may be met by any of the following 3 services: bluetooth, networking, ppp; however, do heed footnote 3 above.

In some cases, if the service will only be used internally on the G3 module by the end product application, the networking script is sufficient because it will start the loopback interface

Optional Service Dependencies

Service	Dependent On
docker.init	cgroups-init
lighttpd	net
mosquitto	net
netmount	net, nfscommon, rpcbind, ntpd
nginx	net
ntpdate	net
ntpd	net
pulseaudio.sh	dbus-1
redis-server	net

---

Footnotes:

8

Setting up the firewall rules is slow because the kernel drivers that implement the actual filters are all compiled as modules. So each time a rule is created that uses a flter that is not already loaded, the kernel module loading infrastructure has to pull another one in from SD or eMMC. While we could build some of the common ones into the kernel and make it faster, Reach Technology consciously chose not to in order to make more RAM memory available to end product applications that don’t need a firewall.

Todo

(Todd) Instructions for package/service setup/configuration go here…

Network

Ethernet

WiFi, BLE

PPP

Firewall

SSH

NTP

NFS Client