David Mirabito
2016-11-03 21:25:04 UTC
Hi,
I have a long running process which needs to know about PTP state in order
to know if the PHC can be trusted, and in what ballpark. So I call out to
"pmc -u 'get DATASET' -d DOMAIN" and the output is easy enough to parse.
This works for the most part; so far so good.
Very occasionally I'm noticing that this fails, and I have a message in
syslog:
user.err pmc: [94758.014] uds: sendto failed: No such file or directory
As far as I can tell from the logs, ptp4l is still running before & after
this event so it's not that it has died or been stopped -- both phc2sys and
ptp4l are reliably logging their rms/max/freq/delay values every 64 seconds
as configures
Also, for what it's worth this device can see both a spectracom and an
arista master:
Oct 20 21:10:41 user.notice ptp4l: [94658.520] port 1: new foreign master
001c73.ffff.b53441-43
Oct 20 21:10:45 user.notice ptp4l: [94662.520] selected best master clock
000cec.fffe.08046f
And it periodically logs (with gaps of 158, 28, 168, 56, 168 seconds
between the messages that I looked at) that:
Oct 20 21:13:23 user.notice ptp4l: [94820.538] selected best master clock
000cec.fffe.08046f
Is this expected, the constant reminder that the same BMC is chosen time
after time, or would this be considered strange?
Now, I can (and should) make my wrapper be immune to the occasional uds
failure, but I'm wondering if this isn't symptomatic of something deeper?
Hacking a bandaid over it without understanding doesn't feel right..
Could there be some race condition on the uds, or other something else
(perhaps related to the BMC decision)?
Additional data points:
* am running in slave-only mode and priority1=255, but otherwise standard.
* running version is 1.6
And & all advice appreciated,
Thanks,
David
I have a long running process which needs to know about PTP state in order
to know if the PHC can be trusted, and in what ballpark. So I call out to
"pmc -u 'get DATASET' -d DOMAIN" and the output is easy enough to parse.
This works for the most part; so far so good.
Very occasionally I'm noticing that this fails, and I have a message in
syslog:
user.err pmc: [94758.014] uds: sendto failed: No such file or directory
As far as I can tell from the logs, ptp4l is still running before & after
this event so it's not that it has died or been stopped -- both phc2sys and
ptp4l are reliably logging their rms/max/freq/delay values every 64 seconds
as configures
Also, for what it's worth this device can see both a spectracom and an
arista master:
Oct 20 21:10:41 user.notice ptp4l: [94658.520] port 1: new foreign master
001c73.ffff.b53441-43
Oct 20 21:10:45 user.notice ptp4l: [94662.520] selected best master clock
000cec.fffe.08046f
And it periodically logs (with gaps of 158, 28, 168, 56, 168 seconds
between the messages that I looked at) that:
Oct 20 21:13:23 user.notice ptp4l: [94820.538] selected best master clock
000cec.fffe.08046f
Is this expected, the constant reminder that the same BMC is chosen time
after time, or would this be considered strange?
Now, I can (and should) make my wrapper be immune to the occasional uds
failure, but I'm wondering if this isn't symptomatic of something deeper?
Hacking a bandaid over it without understanding doesn't feel right..
Could there be some race condition on the uds, or other something else
(perhaps related to the BMC decision)?
Additional data points:
* am running in slave-only mode and priority1=255, but otherwise standard.
* running version is 1.6
And & all advice appreciated,
Thanks,
David