[Linuxptp-devel] [PATCH RFC v3] create systemd service script for ptp4l

[Jacob Keller]

This patch adds a systemd service unit for ptp4l. Currently does not allow
systemd to create any sockets, as this becomes really tricky since there are so
many types of configuration. The initial systemd service will be kept very
simple.

The actual service file is generated in order to include the prefix variables
from the makefile to get included in the systemd service file.

Signed-off-by: Jacob Keller <***@intel.com>
---
makefile | 14 ++++++++++++--
ptp4l.8 | 7 +++++++
ptp4l.service.in | 12 ++++++++++++
3 files changed, 31 insertions(+), 2 deletions(-)
create mode 100644 ptp4l.service.in

diff --git a/makefile b/makefile
index 71dcf0c..96cb0b7 100644
--- a/makefile
+++ b/makefile
@@ -28,6 +28,7 @@ INC = -I$(KBUILD_OUTPUT)/usr/include
VER = -DVER=$(version)
CFLAGS = -Wall $(VER) $(INC) $(DEBUG) $(FEAT_CFLAGS) $(EXTRA_CFLAGS)
LDLIBS = -lm -lrt $(EXTRA_LDFLAGS)
+SRV = ptp4l.service
PRG = ptp4l pmc phc2sys hwstamp_ctl
OBJ = bmc.o clock.o clockadj.o config.o fault.o fsm.o ptp4l.o mave.o \
msg.o phc.o pi.o port.o print.o raw.o servo.o sk.o stats.o tlv.o tmtab.o \
@@ -43,9 +44,16 @@ VPATH = $(srcdir)
prefix = /usr/local
sbindir = $(prefix)/sbin
mandir = $(prefix)/man
+etcdir = $(prefix)/etc
man8dir = $(mandir)/man8
+srvdir = /lib/systemd/system/

-all: $(PRG)
+all: $(PRG) $(SRV)
+
+ptp4l.service: ptp4l.service.in
+ cat $(<) | sed \
+ -e 's_@@sbindir@@_$(sbindir)_g' \
+ -e 's_@@etcdir@@_$(etcdir)_g' >$(@)

ptp4l: $(OBJ)

@@ -70,10 +78,12 @@ force:
install: $(PRG)
mkdir -p $(sbindir) $(man8dir)
install $(PRG) $(sbindir)
+ install -p -m 644 $(SRV) $(srvdir)
install -p -m 644 -t $(man8dir) $(PRG:%=%.8)
+ cp default.cfg $(etcdir)/ptp4l.cfg

clean:
- rm -f $(OBJECTS) $(DEPEND)
+ rm -f $(OBJECTS) $(DEPEND) $(SRV)

distclean: clean
rm -f $(PRG)
diff --git a/ptp4l.8 b/ptp4l.8
index 6f42c1c..2f14b5a 100644
--- a/ptp4l.8
+++ b/ptp4l.8
@@ -395,6 +395,13 @@ of local clock in use. The value is purely informational, having no
effect on the outcome of the Best Master Clock algorithm, and is
advertised when the clock becomes grand master.

+.SH SYSTEMD SERVICE FILE
+
+.B ptp4l.service
+is a systemd service file for use with the systemd init system. This service
+file can be used with systemd and its utilities to manage the ptp4l daemon
+process.
+
.SH TIME SCALE USAGE

.B ptp4l
diff --git a/ptp4l.service.in b/ptp4l.service.in
new file mode 100644
index 0000000..53aed3b
--- /dev/null
+++ b/ptp4l.service.in
@@ -0,0 +1,12 @@
+[Unit]
+Description=LinuxPTP daemon for the IEEE 1588 Time Sync protocol
+After=network.target
+
+[Service]
+# Note that YOU will have to modify ptp4l.cfg to suit your needs. The default
+# configuration will not even start correctly, because it does not specify an
+# interface.
+ExecStart=@@sbindir@@/ptp4l -f @@etcdir@@/ptp4l.cfg -m
+
+[Install]
+WantedBy=multi-user.target

[Miroslav Lichvar]

Post by Jacob Keller
This patch adds a systemd service unit for ptp4l. Currently does not allow
systemd to create any sockets, as this becomes really tricky since there are so
many types of configuration. The initial systemd service will be kept very
simple.
The actual service file is generated in order to include the prefix variables
from the makefile to get included in the systemd service file.
+[Service]
+# Note that YOU will have to modify ptp4l.cfg to suit your needs. The default
+# configuration will not even start correctly, because it does not specify an
+# interface.

Why -m? systemd should be already catching the system log messages,
including their priority.

Would you like to include also a phc2sys service? To avoid
modification of the unit file, it might be useful to get the options
from a file. There could be multiple locations specified in the unit
file for different distribution. In Fedora, it looks like this:

EnvironmentFile=-/etc/sysconfig/phc2sys
ExecStart=/usr/sbin/phc2sys $OPTIONS

Thanks,

[Keller, Jacob E]

Hi Miroslav,

-----Original Message-----
Sent: Tuesday, July 16, 2013 6:15 AM
To: Keller, Jacob E
Subject: Re: [Linuxptp-devel] [PATCH RFC v3] create systemd service
script for ptp4l

Post by Jacob Keller
This patch adds a systemd service unit for ptp4l. Currently does not

allow

Post by Jacob Keller
systemd to create any sockets, as this becomes really tricky since there

are so

Post by Jacob Keller
many types of configuration. The initial systemd service will be kept

very

Post by Jacob Keller
simple.
The actual service file is generated in order to include the prefix

variables

Post by Jacob Keller
from the makefile to get included in the systemd service file.
+[Service]
+# Note that YOU will have to modify ptp4l.cfg to suit your needs. The

default

Post by Jacob Keller
+# configuration will not even start correctly, because it does not

specify an

Post by Jacob Keller
+# interface.

Why -m? systemd should be already catching the system log messages,
including their priority.

I wasn't sure how it worked, but I know system captures the stdout, so I just chose to force ptp4l to log to stdout.

I will do some tests without that and see what the difference makes.

Would you like to include also a phc2sys service? To avoid
modification of the unit file, it might be useful to get the options
from a file. There could be multiple locations specified in the unit
EnvironmentFile=-/etc/sysconfig/phc2sys
ExecStart=/usr/sbin/phc2sys $OPTIONS
Thanks,
--
Miroslav Lichvar

I actually thought about this, but I have some ideas about extending phc2sys in order to automatically change state when the machine becomes the master, etc. I would rather not have a background service like that running when the ptp4l needs to be able to signal it about change of state and we can't do that yet.

Ideally, I want to create a phc2sys type daemon which automatically configures. It will use pps if available, (by checking whether it is supported), and it will determine using the pmc interface whether the machine is in slave or master.

Ideally, it would be able to even detect what ptp device.

If ptp4l is a slave node, it will drive the machine clock by the ptp device.

If ptp4l is a master node, it will drive the ptp device by the machine clock.

Because ptp4l could change in between, it will periodically check and change state when the ptp4l changes state. I don't think we want a background service like this until these features are in place.

- Jake

[Richard Cochran]

Post by Keller, Jacob E
I actually thought about this, but I have some ideas about extending
phc2sys in order to automatically change state when the machine
becomes the master, etc. I would rather not have a background
service like that running when the ptp4l needs to be able to signal
it about change of state and we can't do that yet.

We already have all of ptp4l's state information available by
management queries over UDS.

Post by Keller, Jacob E
If ptp4l is a master node, it will drive the ptp device by the machine clock.

Don't forget about using other time sources, like a GPS over UART.

Post by Keller, Jacob E
Because ptp4l could change in between, it will periodically check
and change state when the ptp4l changes state. I don't think we want
a background service like this until these features are in place.

Agreed. I think both ptp4l and phc2sys have come a long way, but end
users still need to decide for themselves how best to run these
programs. In theory, PTP nodes can configure themselves automatically,
but in practice there are tons of options to consider. It would be
nice to offer a package that does "the right thing" for most people,
without manual configuration, but we are not there yet. We will have
to make sure that ptp4l/phc2sys and ntpd don't both try to steer the
system clock at the same time.

Thanks,
Richard

[Keller, Jacob E]

Richard,

-----Original Message-----
Sent: Tuesday, July 16, 2013 11:15 PM
To: Keller, Jacob E
Subject: Re: [Linuxptp-devel] [PATCH RFC v3] create systemd service
script for ptp4l

Post by Keller, Jacob E
I actually thought about this, but I have some ideas about extending
phc2sys in order to automatically change state when the machine
becomes the master, etc. I would rather not have a background
service like that running when the ptp4l needs to be able to signal
it about change of state and we can't do that yet.

We already have all of ptp4l's state information available by
management queries over UDS.

Yes, ptp4l has the UDS queries. However I was referring to phc2sys not being
extended to use these to try to guess configuration, in the context of
"phc2sys cannot do that yet so I don't think adding a systemd service file
would be the right thing."

Post by Keller, Jacob E
If ptp4l is a master node, it will drive the ptp device by the machine

clock.
Don't forget about using other time sources, like a GPS over UART.

Correct!

Post by Keller, Jacob E
Because ptp4l could change in between, it will periodically check
and change state when the ptp4l changes state. I don't think we want
a background service like this until these features are in place.

Agreed. I think both ptp4l and phc2sys have come a long way, but end
users still need to decide for themselves how best to run these
programs. In theory, PTP nodes can configure themselves automatically,
but in practice there are tons of options to consider. It would be
nice to offer a package that does "the right thing" for most people,
without manual configuration, but we are not there yet. We will have
to make sure that ptp4l/phc2sys and ntpd don't both try to steer the
system clock at the same time.
Thanks,
Richard

There are a lot of configuration options and settings and other things to consider
for getting a good default setup. I don't think phc2sys is ready for that yet. I think ptp4l
is close enough since it can be controlled by the configuration file completely. In addition,
the service won't run by default until the configuration file is edited.

I would like to work on phc2sys to get it more integrated into checking ptp4l's current state,
and determining what the "most common" setup might be, before attempting to create a service for phc2sys.

- Jake

[Richard Cochran]

Post by Keller, Jacob E
I would like to work on phc2sys to get it more integrated into checking ptp4l's current state,
and determining what the "most common" setup might be, before attempting to create a service for phc2sys.

Yes, that all sounds good to me.

You had mentioned something about "signals", and I just wanted to say
that we probably don't need actual signals (using kill(2)) since the
management interface is adequate for getting state information from
ptp4l to phc2sys.

Thanks,
Richard

[Keller, Jacob E]

-----Original Message-----
Sent: Wednesday, July 17, 2013 9:56 PM
To: Keller, Jacob E
Subject: Re: [Linuxptp-devel] [PATCH RFC v3] create systemd service
script for ptp4l

Post by Keller, Jacob E
I would like to work on phc2sys to get it more integrated into checking

ptp4l's current state,

Post by Keller, Jacob E
and determining what the "most common" setup might be, before

attempting to create a service for phc2sys.
Yes, that all sounds good to me.
You had mentioned something about "signals", and I just wanted to say
that we probably don't need actual signals (using kill(2)) since the
management interface is adequate for getting state information from
ptp4l to phc2sys.

You are correct. I was not intending actual signals. I was just intending that phc2sys does not currently use the management interface.

- Jake

Thanks,
Richard