Re: [chrony-dev] Runtime refclock management

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Tue, Oct 03, 2017 at 02:30:09PM -0400, Will Miles wrote:
> I've recently adapted my company's data acquisition platform to use chrony
> to manage the local clock.   However, one of the platform features was the
> ability to add, remove, or reconfigure time sources such as GPS receivers or
> PPS hookups at any time -- so rather than set up some predefined refclock
> inputs (SOC0, SOC1, SHM0, etc.) and come up with some external mechanism to
> track which ones were in use and by whom, it seemed more straightforward to
> extend chrony to allow for "add refclock" and "delete refclock" operations
> via chronyc.   I don't know if this will be generally useful - I've only
> really tested it with the SOCK refclock - but I thought I'd post it up in
> case anyone else was interested.

I think there are cases where this could be useful.

However, there is a problem with permissions. In the current code,
reference clocks are opened before root privileges are dropped, which
means adding refclocks via chronyc would work differently than the
config file. That's not a good user experience. There was a reason why
the SOCK refclock didn't try to remove the socket on exit.

If all refclocks were opened after dropping root privileges, users
would have change permissions/ownership of the devices even if they
were not planning to add them via chronyc. Or, in a worse case, they
would decide to run chronyd with root privileges.

> What is the best way to submit a patch sequence?   Currently I've got it up
> on github at
> https://github.com/willmmiles/chrony/commits/client-refclock-add , but I can
> do something like git format-patch/git send-email if that's more practical.

Sending patches to the list is prefered.

> Comments are very welcome - if this is a feature you'd be interested in
> adopting upstream, but there's further work to do or a different approach
> you'd prefer to see, please let me know and I'd be happy to improve it in
> whatever way I can.

I had a quick look at the patches and I think the idea is well
implemented. I think I'd have just few comments about coding style,
memory leaks and maybe try to deduplicate some of the code in cmdmon.c
and client.c. The parser of the delete command should be able to
handle "refclock" as a hostname for compatibility. The Linux seccomp
filter would probably need to be updated to allow all syscalls that
can be made when opening refclocks.

With the permission issue, I'm not sure if this is really worth it.
I'll need to think about it.

Before you implemented the new commands, have you tried modifying the
config file and restarting chronyd? With the dumpdir directive and the
-r option, the timekeeping service should be restored very quickly.

If it didn't work well for you, I'm wondering if it wouldn't be better
to focus on improving this feature instead of adding refclock specific
commands.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.