OK, there are several points I can bring up.  The Before and After clauses 
in a systemd unit file only affect the ordering of unit files and not the 
dependency.  For a dependency, you will want either *wants* or *requires* to 
specify a dependency.  The requires clause is a hard dependency (the unit 
file or device must exist and must run), while the wants clause does not 
require the unit file or device, but will bring it in if it exists.  This 
is my main ntpd.service file:

[Unit]
Description=Network Time Service daemon
After=init-gps.service
After=dev-gps0.device
Requires=dev-gps0.device
Wants=init-gps.service

[Service]
Type=simple
ExecStart=/usr/local/bin/ntpd -Nng
[Install]
WantedBy=multi-user.target

You can see that it has a hard dependency on dev-gps0.device.  No 
device, and NTPd will not run. 

On my device, init-gps.service is just a wrapper to a shell script that 
sends commands to the GPS serial port;  I'm not using it at the moment, so 
it is just listed as a want--not a hard dependency.

The other part is in /etc/udev/rules.d/10-gps.rules and is probably similar 
to your rule except for one item:

SUBSYSTEM=="tty", KERNEL=="ttyO1", NAME="ttyO1", SYMLINK="gps0",
*TAG="systemd"*

The TAG specification is very important and indicates that systemd needs to 
know about your device.  

When implemented properly, your NTPd unit file will wait on the device 
until the symlink is created.  Then NTP will be started.  I recommend not 
forking NTPd -- the startup options I have listed, -Nng (don't fork, 
highest priority, no limits on initial time skew), appear to be the most 
optimal.  I don't presently use ntpdate to "presync" the device.  

With a standby battery on my device (powering an RTC and the GPS), I can 
attain a reboot cycle of less than a minute from U-boot startup until NTPd 
starts and acquires the GPS.  I haven't yet optimized it, but I am very 
happy with my results so far.

(BTW, this has nothing whatsoever to do with the GPS constellation, etc.  
It should be a use-case that my (our) NTP device should be able to come up 
from a cold start with no fix and start talking with NTPd, whereas it will 
wait for a fix and choose other peers while it is doing so.)

This is my finished clock, known as BB-NTPd. <http://twitpic.com/dsvr33>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to