Re: [ntp:questions] Handle ntp conf modification when ntp is already running
(Found unsent in my draft folder) Arthur Lambert writes: Hi, Thank you for all your answer. So in fact Jochen, even if I need for some reason to handle dynamic change on ntp.conf, you are telling me that it is cleaner and better to restart the daemon ? I'm not sure I'd agree that it is better/cleaner to restart the daemon. There may be some corner cases where the dynamic config stuff doesn't let you do/undo everything - in that case it would be better to find and fix these cases. I am currently putting some modification in my ntp conf file thanks to tr69 protocols. Moreover due to security constraints it is very hard for me to restart the ntp daemon.. It is quite strange that noone try to patch ntp daemon to handle runtime modification on ntp conf. Most folks have a strong preference for letting ntpd run for as long as possible. And I think you'll find that there can be a lot to do to undo everything that is in-place just to cleanly re-process an ntp.conf file. I also tried to use confi-from-file feature from ntpq without success. I add a ntp url in my ntp conf and run ntpq -c config-from-file /etc/ntp.conf. Then I am not able to see my new ntp url by running ntpq -p command. Have you tried running those commands from the ntpq CLI, with the :config directive? I also don't know if anybody has written a test case for the config-from-file stuff. That might be a good place to start - you can use the 'saveconfig' directive to test to see if your changes have been made. If I am able to create a clean patch to handle runtime modification I will be happy to share it. Please consider discussing your ideas with folks - you are looking at a lot of work and if you want to see your patches included in the main distribution it would be best if we all agreed on how things look. H -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On Thu, Apr 10, 2014 at 08:20:59PM +, Harlan Stenn wrote: Rob writes: Furthermore, the simple solution of having SIGHUP perform an exec of the same binary, thus in fact restarting the entire process and losing all state information, is not the only possible solution. If the current process has chroot()ed, how do you re-exec? How do you handle the things that are done before the chroot()? Again, I haven't looked at the code to be sure, but I believe there are some things that will behave differently if they are attempted from the chroot() target. Sure, one could have a top-level master process that simply waits for the chroot()ed subprocess to die and then restarts it, but we're starting to get in to a lot of wheel-reinventing here, and would this really be worth the overhead on a program that is already larger and more complicated than many folks want? That sounds like a horrible hack. Even without chroot it will be difficult. If the ntpd process dropped root privileges after start, it won't be able to re-exec and it may not have permissions to open newly added refclocks or reread the keys, for instance. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Amongst the many reasons why we did not let SIGHUP restart the daemon was that back in the old days we used modem drivers a lot more often. The HUP signal was generic - it was not really associated with any specific device. I think you are confusing two things. A modemline attached to a process does not send SIGHUP when the modem drops carrier unless the process has that modemline as a controlling TTY. So, when you have a daemon like ntpd that would open a modemline for some communication, it will not get the SIGHUP from there. SIGHUP as sent between processes to force a configuration reload is completely unrelated to SIGHUP as sent by tty lines when carrier drops. (and used to save files in editors, terminate an interactive session, etc) Sure it is confusing that the same signal is used. Probably there should have been a separate SIGRECONF or similar. However, in those days designers worried about using up a small number space, like signal numbers that are bitnumbers in a word, and thus limited to 1-31. I'm still missing something then. Unix signal handlers don't get any callback context. So how can the handler know if it got a sighup because of a TTY HUP as opposed to the signal arriving because the user wants to do a reload? It cannot identify that. But services are not supposed to get TTY HUP signals and normal user programs (shells, editors) are not supposed to use SIGHUP to re-read configuration files. And I used to do a lot of signal stuff in general and SIGHUP processing (both re ttys and for reload) but haven't done this in Years. I may be misremembering. What you write is correct in itself. If you really want to use SIGHUP for two things, I suppose it would be possible to get the serial line state in the signal handler and check the DCD state, and when it has become false it could be assumed that the SIGHUP was caused by that. (at least when DCD was true before) Furthermore, the simple solution of having SIGHUP perform an exec of the same binary, thus in fact restarting the entire process and losing all state information, is not the only possible solution. If the current process has chroot()ed, how do you re-exec? How do you handle the things that are done before the chroot()? Again, I haven't looked at the code to be sure, but I believe there are some things that will behave differently if they are attempted from the chroot() target. I think the re-exec is not a preferred way to do it anyway. But some early Unix daemons did that. That was coded before chroot and dropping privileges after startup became commonplace. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
It seems clear to me that once again, we have learned that in general we cannot expect ntpd to restart from scratch without stopping and restarting the process. Again, items which make this infeasible include: - chroot - drop privs As the above features are probably the most important to the same folks who would want to make signbificant changes to the config file, what value is there in continuing this specific aspect of this thread? The ':config' directive should give folks relatively complete control over normal runtime configuration. There are a few directives that are expressly prohibited from being changed by ':config' because of security concerns. The 'saveconfig' directive should also be a fine way to save state for restart. We have a test framework that should allow us to make sure that these mechanisms work as expected. What's the problem with making sure that ':config' and 'saveconfig' are doing all that is needed? -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
Rob wrote: For Arthur: you need to modify the ntp.conf in case the system is rebooted outside your control (it will then use the values from ntp.conf) and at the same time use the above method to add the new server immediately. Then you do not need to restart ntpd and you can still change the config. Right. OF COURSE ntpd should simply listen for SIGHUP and when it is received re-read the config file. Like almost all Unix daemons do. Here's the crux of the matter: ntpd is _not_ a Unix daemon, or at least not just that: The same code runs on many different operating systems, some of which don't implement SIGHUP at all, or at least not in a compatible manner. However, you will have a hard time convincing the group here, as you already found out. I personally believe it would be nice if we did support SIGHUP on platforms where that is easily implementable, otoh ntpd is moving strongly towards a more or less auto-configurable setup: A single 'pool pool.ntp.org' in the ntp.conf file (possibly added as default if started without a config file at all), and then the ntpd process will automatically redo the dns lookup every hour or so, pruning away the worst-performing servers and replacing them with new entries from the dns pool. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
Amongst the many reasons why we did not let SIGHUP restart the daemon was that back in the old days we used modem drivers a lot more often. The HUP signal was generic - it was not really associated with any specific device. It looks like that code is now gone from the distribution, but there are still a few places in the code (lib/isc/unix/app.c and libntp/work_fork.c) that would need to be looked at. Additionally, on non-windows platforms somebody would have to look at SIGDIE1. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
Harlan Stenn st...@ntp.org wrote: Amongst the many reasons why we did not let SIGHUP restart the daemon was that back in the old days we used modem drivers a lot more often. The HUP signal was generic - it was not really associated with any specific device. I think you are confusing two things. A modemline attached to a process does not send SIGHUP when the modem drops carrier unless the process has that modemline as a controlling TTY. So, when you have a daemon like ntpd that would open a modemline for some communication, it will not get the SIGHUP from there. SIGHUP as sent between processes to force a configuration reload is completely unrelated to SIGHUP as sent by tty lines when carrier drops. (and used to save files in editors, terminate an interactive session, etc) Sure it is confusing that the same signal is used. Probably there should have been a separate SIGRECONF or similar. However, in those days designers worried about using up a small number space, like signal numbers that are bitnumbers in a word, and thus limited to 1-31. Furthermore, the simple solution of having SIGHUP perform an exec of the same binary, thus in fact restarting the entire process and losing all state information, is not the only possible solution. It is also possible to make SIGHUP parse the configfile into a new datastructure, then let the program determine the differences between the old and new situation, and perform the necessary changes (like adding and removing servers), without disturbing existing associations and the frequency control loop. This of course requires a lot more effort, especially when this was not designed in from the start. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On 10.04.2014 14:00, questions-requ...@lists.ntp.org digested: From: Terje Mathisen terje.mathi...@tmsw.no Rob wrote: OF COURSE ntpd should simply listen for SIGHUP and when it is received re-read the config file. Like almost all Unix daemons do. Here's the crux of the matter: ntpd is _not_ a Unix daemon, or at least not just that: The same code runs on many different operating systems, some of which don't implement SIGHUP at all, or at least not in a compatible manner. Now this sounds dangerously close to ntpd cannot possibly use a config file, because it is supposed to be running on various OSes with incompatible character and end-of-line encodings ... From: Harlan Stenn st...@ntp.org Amongst the many reasons why we did not let SIGHUP restart the daemon was that back in the old days we used modem drivers a lot more often. The HUP signal was generic - it was not really associated with any specific device. I wouldn't be surprised if spurious SIGHUPs were still occuring (and possibly reaching unrelated daemon processes) today - just think of how many DSL routers happen to have a unixoid OS and are actually running a pppd (whose manpage mentions HUPs a lot). Point is, for daemons *other* than ntpd, rereading the config that nobody did edit will likely have no noticeable effect at all. For ntpd, with the round robin DNS pools yielding different servers every time you resolve, and possibly losing status even for those servers that did *not* change ... things might look different. Then again, it's not like there are no established unixoid methods *other* than HUP - from USR1 (no example whose name I'd remember off the top of my head) to polling the config file's stat() periodically (a la /etc/crontab) to a simple CLI via local special files (a la Nagios command pipe, or even echo 1 /proc/sys/foo/bar) to opaque IPC hidden behind a dedicated util's command line options (a la apachectl, or fetchmail --quit). At the end of the day, lots of people - and the most important clustering solutions - won't care to look past the OS' meta-command, be it service mumblefoo reload or svcadm restart mumblefoo, as long as that *works*. :-} Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
Rob writes: Harlan Stenn st...@ntp.org wrote: Amongst the many reasons why we did not let SIGHUP restart the daemon was that back in the old days we used modem drivers a lot more often. The HUP signal was generic - it was not really associated with any specific device. I think you are confusing two things. A modemline attached to a process does not send SIGHUP when the modem drops carrier unless the process has that modemline as a controlling TTY. So, when you have a daemon like ntpd that would open a modemline for some communication, it will not get the SIGHUP from there. SIGHUP as sent between processes to force a configuration reload is completely unrelated to SIGHUP as sent by tty lines when carrier drops. (and used to save files in editors, terminate an interactive session, etc) Sure it is confusing that the same signal is used. Probably there should have been a separate SIGRECONF or similar. However, in those days designers worried about using up a small number space, like signal numbers that are bitnumbers in a word, and thus limited to 1-31. I'm still missing something then. Unix signal handlers don't get any callback context. So how can the handler know if it got a sighup because of a TTY HUP as opposed to the signal arriving because the user wants to do a reload? And I used to do a lot of signal stuff in general and SIGHUP processing (both re ttys and for reload) but haven't done this in Years. I may be misremembering. Furthermore, the simple solution of having SIGHUP perform an exec of the same binary, thus in fact restarting the entire process and losing all state information, is not the only possible solution. If the current process has chroot()ed, how do you re-exec? How do you handle the things that are done before the chroot()? Again, I haven't looked at the code to be sure, but I believe there are some things that will behave differently if they are attempted from the chroot() target. Sure, one could have a top-level master process that simply waits for the chroot()ed subprocess to die and then restarts it, but we're starting to get in to a lot of wheel-reinventing here, and would this really be worth the overhead on a program that is already larger and more complicated than many folks want? It is also possible to make SIGHUP parse the configfile into a new datastructure, then let the program determine the differences between the old and new situation, and perform the necessary changes (like adding and removing servers), without disturbing existing associations and the frequency control loop. This of course requires a lot more effort, especially when this was not designed in from the start. Yes, and it is something we can slate in for at least consideration for the next rewrite of the codebase. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On 10/04/14 17:51, Rob wrote: A modemline attached to a process does not send SIGHUP when the modem drops carrier unless the process has that modemline as a controlling TTY. A daemon is generally a session leader. The first TTY it opens will become its controlling terminal. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
David Woolley writes: A daemon is generally a session leader. The first TTY it opens will become its controlling terminal. Not if the terminal is opened with O_NOCTTY. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
Hi,
Thank you for all your answer.
So in fact Jochen, even if I need for some reason to handle dynamic
change on ntp.conf, you are telling me that it is cleaner and better
to restart the daemon ?
I am currently putting some modification in my ntp conf file thanks to
tr69 protocols. Moreover due to security constraints it is very hard
for me to restart the ntp daemon.. It is quite strange that noone try
to patch ntp daemon to handle runtime modification on ntp conf.
I also tried to use confi-from-file feature from ntpq without success.
I add a ntp url in my ntp conf and run ntpq -c config-from-file
/etc/ntp.conf. Then I am not able to see my new ntp url by running
ntpq -p command.
If I am able to create a clean patch to handle runtime modification I
will be happy to share it.
Regards,
Arthur.
2014-04-09 5:34 GMT+02:00 E-Mail Sent to this address will be added to
the BlackLists Null@blacklist.anitech-systems.invalid:
On 4/8/2014 2:49 PM, William Unruh wrote:
On 2014-04-08, Arthur Lambert wrote:
-|-|-|-|-|-|
I am currently using ntpd for my project.
My need is to be able to use new ntp url when I put a
new url in ntp.conf even if the ntp daemon is already running.
Currently, I need to kill and reboot ntpd to be able to
use the new ntp url set in my configuration file.
i guess that my solution right now is to start ntpd in a
hat process to be able to restart it if I detect a change
in ntp conf file.
Do I have really to restart ntpd to see new ntp url ?
I tried to check option on ntpd to find a way to handle
this case but I am not able to see this feature in the
current implementation of ntpd
You would likely need to use a fairly bleeding edge Dev Release.
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/
http://archive.ntp.org/ntp4/ntp-dev/
e.g. Development 4.2.7p439 2014/04/03
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p439.tar.gz
http://archive.ntp.org/ntp4/ntp-dev/ntp-dev-4.2.7p439.tar.gz
I believe you can tell ntpd anthing that ntp.conf would by using ntpq.
:config
I do not believe that there is a way of telling it to reread the .conf
file.
config-from-file filename
I haven't tried either (yet).
http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html
or e.g. {In the case of the dev ver I last downloaded}
ntp-dev-4.2.7p418/html/ntpq.html See: Control-Message-Commands
ntp-dev-4.2.7p418/ntpq/ntpq.html#Control-Message-Commands
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
--
- Arthur LAMBERT
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
Arthur Lambert wrote:
Hi,
Thank you for all your answer.
So in fact Jochen, even if I need for some reason to handle dynamic
change on ntp.conf, you are telling me that it is cleaner and better
to restart the daemon ?
I am currently putting some modification in my ntp conf file thanks to
tr69 protocols. Moreover due to security constraints it is very hard
for me to restart the ntp daemon.. It is quite strange that noone try
to patch ntp daemon to handle runtime modification on ntp conf.
I also tried to use confi-from-file feature from ntpq without success.
I add a ntp url in my ntp conf and run ntpq -c config-from-file
/etc/ntp.conf. Then I am not able to see my new ntp url by running
ntpq -p command.
Hi
I've just tried adding an extra server using config-from-file
(ntp-dev-4.2.7p439 NetBSD-6)
ntpq
config-from-file ntp.conf_add.2014040901
Sending configurstion file, one line at a time.
Keyid: 1
MD5 Password:
Line No: 1 Config Succeeded: server -4 xxx.x.xx.xx minpoll 8 maxpoll
10 iburst
Done sending file
ntpq quit
ntpq -p shows the added server
remote refid st tpoll reach delay offset jitter
+xxx.x.xx.xx x 2 u 193 256 7 22.334 2.349 0.113
David
If I am able to create a clean patch to handle runtime modification I
will be happy to share it.
Regards,
Arthur.
2014-04-09 5:34 GMT+02:00 E-Mail Sent to this address will be added to
the BlackLists Null@blacklist.anitech-systems.invalid:
On 4/8/2014 2:49 PM, William Unruh wrote:
On 2014-04-08, Arthur Lambert wrote:
-|-|-|-|-|-|
I am currently using ntpd for my project.
My need is to be able to use new ntp url when I put a
new url in ntp.conf even if the ntp daemon is already running.
Currently, I need to kill and reboot ntpd to be able to
use the new ntp url set in my configuration file.
i guess that my solution right now is to start ntpd in a
hat process to be able to restart it if I detect a change
in ntp conf file.
Do I have really to restart ntpd to see new ntp url ?
I tried to check option on ntpd to find a way to handle
this case but I am not able to see this feature in the
current implementation of ntpd
You would likely need to use a fairly bleeding edge Dev Release.
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/
http://archive.ntp.org/ntp4/ntp-dev/
e.g. Development 4.2.7p439 2014/04/03
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p439.tar.gz
http://archive.ntp.org/ntp4/ntp-dev/ntp-dev-4.2.7p439.tar.gz
I believe you can tell ntpd anthing that ntp.conf would by using ntpq.
:config
I do not believe that there is a way of telling it to reread the .conf
file.
config-from-file filename
I haven't tried either (yet).
http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html
or e.g. {In the case of the dev ver I last downloaded}
ntp-dev-4.2.7p418/html/ntpq.html See: Control-Message-Commands
ntp-dev-4.2.7p418/ntpq/ntpq.html#Control-Message-Commands
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
David Lord sn...@lordynet.org wrote: Arthur Lambert wrote: Hi, Thank you for all your answer. So in fact Jochen, even if I need for some reason to handle dynamic change on ntp.conf, you are telling me that it is cleaner and better to restart the daemon ? I am currently putting some modification in my ntp conf file thanks to tr69 protocols. Moreover due to security constraints it is very hard for me to restart the ntp daemon.. It is quite strange that noone try to patch ntp daemon to handle runtime modification on ntp conf. I also tried to use confi-from-file feature from ntpq without success. I add a ntp url in my ntp conf and run ntpq -c config-from-file /etc/ntp.conf. Then I am not able to see my new ntp url by running ntpq -p command. Hi I've just tried adding an extra server using config-from-file (ntp-dev-4.2.7p439 NetBSD-6) ntpq config-from-file ntp.conf_add.2014040901 Sending configurstion file, one line at a time. Keyid: 1 MD5 Password: Line No: 1 Config Succeeded: server -4 xxx.x.xx.xx minpoll 8 maxpoll 10 iburst Done sending file ntpq quit ntpq -p shows the added server remote refid st tpoll reach delay offset jitter +xxx.x.xx.xx x 2 u 193 256 7 22.334 2.349 0.113 David Indeed it can be done that way. For Arthur: you need to modify the ntp.conf in case the system is rebooted outside your control (it will then use the values from ntp.conf) and at the same time use the above method to add the new server immediately. Then you do not need to restart ntpd and you can still change the config. OF COURSE ntpd should simply listen for SIGHUP and when it is received re-read the config file. Like almost all Unix daemons do. However, you will have a hard time convincing the group here, as you already found out. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
Hi Rob, I know that my question can be stupid but I am not very familiar with open source project. If tomorrow someone decides to develop a feature on ntp. Who can decide if the feature will be integrated to the trunk of the project ? People have to convince the main guys of the projects ? So I will use the above method to handle my runtime modification. If I find free time to handle SIGHUP and if I am able to write a proper code to do it, I will share my changes in this topic. 2014-04-09 18:04 GMT+02:00 Rob nom...@example.com: David Lord sn...@lordynet.org wrote: Arthur Lambert wrote: Hi, Thank you for all your answer. So in fact Jochen, even if I need for some reason to handle dynamic change on ntp.conf, you are telling me that it is cleaner and better to restart the daemon ? I am currently putting some modification in my ntp conf file thanks to tr69 protocols. Moreover due to security constraints it is very hard for me to restart the ntp daemon.. It is quite strange that noone try to patch ntp daemon to handle runtime modification on ntp conf. I also tried to use confi-from-file feature from ntpq without success. I add a ntp url in my ntp conf and run ntpq -c config-from-file /etc/ntp.conf. Then I am not able to see my new ntp url by running ntpq -p command. Hi I've just tried adding an extra server using config-from-file (ntp-dev-4.2.7p439 NetBSD-6) ntpq config-from-file ntp.conf_add.2014040901 Sending configurstion file, one line at a time. Keyid: 1 MD5 Password: Line No: 1 Config Succeeded: server -4 xxx.x.xx.xx minpoll 8 maxpoll 10 iburst Done sending file ntpq quit ntpq -p shows the added server remote refid st tpoll reach delay offset jitter +xxx.x.xx.xx x 2 u 193 256 7 22.334 2.349 0.113 David Indeed it can be done that way. For Arthur: you need to modify the ntp.conf in case the system is rebooted outside your control (it will then use the values from ntp.conf) and at the same time use the above method to add the new server immediately. Then you do not need to restart ntpd and you can still change the config. OF COURSE ntpd should simply listen for SIGHUP and when it is received re-read the config file. Like almost all Unix daemons do. However, you will have a hard time convincing the group here, as you already found out. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- - Arthur LAMBERT ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
Arthur Lambert lambertarthu...@gmail.com wrote: Hi Rob, I know that my question can be stupid but I am not very familiar with open source project. If tomorrow someone decides to develop a feature on ntp. Who can decide if the feature will be integrated to the trunk of the project ? People have to convince the main guys of the projects ? It depends on the actual project at hand, but usually there are some core developers who decide what patches will be accepted. When this would not be the case, the result would quickly be a big mess. Of course when you develop the software for your embedded device, you can always decide to solve the problem for yourself. When you put the patches (sources) somewhere on a website or mail them to anyone who asks, there is nothing that can go wrong. When you only use the binaries inside an organisation and not distribute them (either as software or embedded in a device you distribute) you don't even have to do that. So I will use the above method to handle my runtime modification. If I find free time to handle SIGHUP and if I am able to write a proper code to do it, I will share my changes in this topic. That would be very nice. However, don't be disappointed when somehow refuses to add them to the standard distributed version. I think many users would welcome them very much, but that does not mean the lead developers do. They often have very expressed opinions on things they did not come up with themselves. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
Arthur Lambert wrote: Hi, I am currently using ntpd for my project. My need is to be able to use new ntp url when I put a new url in ntp.conf even if the ntp daemon is already running. Currently, I need to kill and reboot ntpd to be able to use the new ntp url set in my configuration file. i guess that my solution right now is to start ntpd in a hat process to be able to restart it if I detect a change in ntp conf file. Do I have really to restart ntpd to see new ntp url ? I tried to check option on ntpd to find a way to handle this case but I am not able to see this feature in the current implementation of ntpd Hi I've lived with your problem since 1997 when I switched from mostly running chrony to mostly running ntp. I never saw it as a problem. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
do you mean a new association? Like the ntpdc addserver command? -Original Message- From: questions-bounces+greg.dowd=microsemi@lists.ntp.org [mailto:questions-bounces+greg.dowd=microsemi@lists.ntp.org] On Behalf Of David Lord Sent: Tuesday, April 08, 2014 6:39 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Handle ntp conf modification when ntp is already running Arthur Lambert wrote: Hi, I am currently using ntpd for my project. My need is to be able to use new ntp url when I put a new url in ntp.conf even if the ntp daemon is already running. Currently, I need to kill and reboot ntpd to be able to use the new ntp url set in my configuration file. i guess that my solution right now is to start ntpd in a hat process to be able to restart it if I detect a change in ntp conf file. Do I have really to restart ntpd to see new ntp url ? I tried to check option on ntpd to find a way to handle this case but I am not able to see this feature in the current implementation of ntpd Hi I've lived with your problem since 1997 when I switched from mostly running chrony to mostly running ntp. I never saw it as a problem. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On Tue, Apr 8, 2014 at 12:24 PM, Dowd, Greg greg.d...@microsemi.com wrote: do you mean a new association? Like the ntpdc addserver command? Beyond the limited set of options and unpleasant syntax of addserver isn't ntpdc deprecated? (and disabled by default in recent builds) Perhaps :config and config-from-file are the intended replacements. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
Hi David, I don't get your point. You know that we can live just with fire ? Why do we invent electricity And computer ? This is exactly the same here. I change the channel on my tv, I dont want to reboot it to get the new tv channel It's worked ok but it a very strange choice of architecture. But I can guess with your answer that I cannot handle modification on my ntp conf without restart it. I will try to patch it to get it work with my need. Thanks, Arthur. Le 8 avr. 2014 16:19, David Lord sn...@lordynet.org a écrit : Arthur Lambert wrote: Hi, I am currently using ntpd for my project. My need is to be able to use new ntp url when I put a new url in ntp.conf even if the ntp daemon is already running. Currently, I need to kill and reboot ntpd to be able to use the new ntp url set in my configuration file. i guess that my solution right now is to start ntpd in a hat process to be able to restart it if I detect a change in ntp conf file. Do I have really to restart ntpd to see new ntp url ? I tried to check option on ntpd to find a way to handle this case but I am not able to see this feature in the current implementation of ntpd Hi I've lived with your problem since 1997 when I switched from mostly running chrony to mostly running ntp. I never saw it as a problem. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On 2014-04-08, Arthur Lambert lambertarthu...@gmail.com wrote: But I can guess with your answer that I cannot handle modification on my ntp conf without restart it. I will try to patch it to get it work with my need. ntpd parses the configuration file at start-up. ntpd does not monitor the configuration file for changes. ntpd does not, AFAIK, reparse the configuration file in response to any signals (e.g. SIGHUP). Please contibute a patch with your changes to our BTS at http://bugs.ntp.org [---=| TOFU protection by t-prot: 31 lines snipped |=---] ... -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On 08.04.2014 20:30, questions-requ...@lists.ntp.org digested: From: Arthur Lambert lambertarthu...@gmail.com Hi David, I don't get your point. You know that we can live just with fire ? Why do we invent electricity And computer ? This is exactly the same here. I change the channel on my tv, I dont want to reboot it to get the new tv channel It's worked ok but it a very strange choice of architecture. But I can guess with your answer that I cannot handle modification on my ntp conf without restart it. I will try to patch it to get it work with my need. As Paul already noted, there *are* mechanisms to change aspects of the configuration during runtime, but they've gotten *quite* disparate from the effects that a restart with a changed config file has, up to and including downright missing functionality. In other words, you *do* have an interest to check whether the changed config file does work as expected while you're still sitting there with the editor at hand. Or else, to stay in your analogy, you might find that your TV happily changed channels for years on end, but flat out fails to turn on after a power failure (or OS update, or ...) finally rebooted it for you. From a theoretical point of view, restarting ntpd on a single server will force it to drop its working stratum and associations for a while, but its system clock should continue to be fine-tuned according to the latest results (loaded from the drift file) with virtually no interruption. That shouldn't be a problem unless other hosts sync against that one - in which case having more than one local server for your clients would be the proper fix. There's no genuine advantage (caches loaded, more statistic Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On 08.04.2014 22:28, Jochen Bern wrote: There's no genuine advantage (caches loaded, more statistic ...al data gathered, priorization through higher uptime, ...) for an ntpd in having a higher runtime. (Sorry, badly placed touchpad sent the original mail prematurely.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On 2014-04-08, Arthur Lambert lambertarthu...@gmail.com wrote: Hi, I am currently using ntpd for my project. My need is to be able to use new ntp url when I put a new url in ntp.conf even if the ntp daemon is already running. Currently, I need to kill and reboot ntpd to be able to use the new ntp url set in my configuration file. i guess that my solution right now is to start ntpd in a hat process to be able to restart it if I detect a change in ntp conf file. Do I have really to restart ntpd to see new ntp url ? I tried to check option on ntpd to find a way to handle this case but I am not able to see this feature in the current implementation of ntpd I believe you can tell ntpd anthing that ntp.conf would by using ntpq. I do not believe that there is a way of telling it to reread the .conf file. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On 4/8/2014 2:49 PM, William Unruh wrote:
On 2014-04-08, Arthur Lambert wrote:
-|-|-|-|-|-|
I am currently using ntpd for my project.
My need is to be able to use new ntp url when I put a
new url in ntp.conf even if the ntp daemon is already running.
Currently, I need to kill and reboot ntpd to be able to
use the new ntp url set in my configuration file.
i guess that my solution right now is to start ntpd in a
hat process to be able to restart it if I detect a change
in ntp conf file.
Do I have really to restart ntpd to see new ntp url ?
I tried to check option on ntpd to find a way to handle
this case but I am not able to see this feature in the
current implementation of ntpd
You would likely need to use a fairly bleeding edge Dev Release.
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/
http://archive.ntp.org/ntp4/ntp-dev/
e.g. Development 4.2.7p439 2014/04/03
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p439.tar.gz
http://archive.ntp.org/ntp4/ntp-dev/ntp-dev-4.2.7p439.tar.gz
I believe you can tell ntpd anthing that ntp.conf would by using ntpq.
:config
I do not believe that there is a way of telling it to reread the .conf
file.
config-from-file filename
I haven't tried either (yet).
http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html
or e.g. {In the case of the dev ver I last downloaded}
ntp-dev-4.2.7p418/html/ntpq.html See: Control-Message-Commands
ntp-dev-4.2.7p418/ntpq/ntpq.html#Control-Message-Commands
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
