OP5 Monitor - smsd service not starting because smsd.working runtime file cannot be created

This article is to provide a quick troubleshooting guide for when the smsd service fails to start due to misconfigured runtime directory.

This usually happens when the example /etc/smsd.conf provided with the smstools package has been edited to point to a directory without checking that the directory exists.

Example output which may be produced as a result of the above misconfiguration:

[root@op5-system ~]# systemctl status smsd.service 
● smsd.service - smsd
Loaded: loaded (/usr/lib/systemd/system/smsd.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2020-02-12 12:45:55 GMT; 1s ago
Process: 20588 ExecStart=/usr/sbin/smsd -t (code=exited, status=1/FAILURE)
Process: 20585 ExecStartPre=/bin/chown smstools:smstools /var/run/smsd.working (code=exited, status=0/SUCCESS)
Process: 20579 ExecStartPre=/bin/touch /var/run/smsd.working (code=exited, status=0/SUCCESS)
Process: 20574 ExecStartPre=/bin/chown smstools:smstools /var/run/smsd.pid (code=exited, status=0/SUCCESS)
Process: 20571 ExecStartPre=/bin/touch /var/run/smsd.pid (code=exited, status=0/SUCCESS)
Main PID: 20588 (code=exited, status=1/FAILURE)

Feb 12 12:45:55 op5-system systemd[1]: Starting smsd...
Feb 12 12:45:55 op5-system systemd[1]: Started smsd.
Feb 12 12:45:55 op5-system smsd[20588]: Infofile /var/run/smsd/smsd.working cannot be created: No such file or directory
Feb 12 12:45:55 op5-system smsd[20588]: There was 1 major problem found.
Feb 12 12:45:55 op5-system systemd[1]: smsd.service: main process exited, code=exited, status=1/FAILURE
Feb 12 12:45:55 op5-system systemd[1]: Unit smsd.service entered failed state.
Feb 12 12:45:55 op5-system systemd[1]: smsd.service failed.
Hint: Some lines were ellipsized, use -l to show in full.

Case in point: customised /etc/smsd.conf (edited by end user):

# Example smsd.conf. Read the manual for a description
devices=GSM1
logfile=/var/log/smsd/smsd.log
#loglevel=8
# Changed loglevel 170419 //CG
loglevel=7
user=root
infofile=/var/run/smsd/smsd.working
pidfile=/var/run/smsd/smsd.pid
smart_logging=yes
outgoing=/var/spool/sms/outgoing
checked=/var/spool/sms/checked
failed=/var/spool/sms/failed
sent=/var/spool/sms/sent

[GSM1]
incoming=no
rtscts=no
device=@x.x.x.x:4001
baudrate=115200
init=AT&W

The /var/run/smsd directory is a non-standard configuration directory added by the end user, and has created a problem because this directory had not also been created to accommodate successful startup of the service.

QUICK FIX:

A quick fix is to ensure that any custom target directory specified in /etc/smsd.conf also exists on disk, and is owned by smstools:smstools.

# mkdir /var/run/smsd && chown smstools: /var/run/smsd

# systemctl restart smsd.service

RECOMMENDED FIX:

The best course of action though, would have been to revert to the standard directory layout as shown in the example /etc/smsd.conf as follows:

# Example smsd.conf. Read the manual for a description

devices = GSM1
logfile = /var/log/smsd/smsd.log
loglevel = 5
user = root
infofile = /var/run/smsd.working
pidfile = /var/run/smsd.pid
# 3.1.5 introduced smart logging
# once your configuration is OK, set log level lower (5 is good in most cases)
smart_logging = yes

[GSM1] <=== (configure this section as per your modem)
device = /dev/ttyS0
incoming = yes
#pin = 1111

Hopefully this has provided some insight into how to get out of, not only this specific misconfiguration, but similar situations where end user custom edits have broken an application or service.