ntp daemon not reconfigured by /etc/network

[Perry E. Metzger]

Binary package hint: ntp

If you have a laptop that roams, you want your ntp daemon to restart when you change networks so that your time remains synchronized. This would normally be done by scripts in /etc/network/if-up.d/

/etc/network/if-up.d/ntp and /etc/network/ntp-server have a small problem with them.

Look at the files. Observe the lines saying:

  # remove (or comment out) the next line if your network addresses change
  exit 0

Those lines effectively disable the files. They need to be removed. Then they will properly restart ntpd when a machine roams. I'm not quite clear on why the comments are there to begin with, as a machine with a static address will never invoke the scripts.

This will take mere moments for someone to fix.

[Hew (hew)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? The files you mentioned are not present in my testing with Intrepid. Can you try with the latest Ubuntu release, Hardy Heron? Thanks in advance.

[Perry E. Metzger (perry-piermont)]

Hew <email address hidden> writes:
> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. You reported this bug a while ago and there hasn't been
> any activity in it recently.

That's not my fault. I reported a bug and no one bothered to try
fixing it. That doesn't mean the bug has vanished.

> We were wondering is this still an issue for you?

So far as I know, yes.

> The files you mentioned are not present in my testing with
> Intrepid. Can you try with the latest Ubuntu release, Hardy Heron?
> Thanks in advance.

I see no evidence of the problem having been fixed in Hardy.

If the files don't exist in Intrepid, that's because they've either
been replaced with another mechanism for restarting things after
sleep, which might or might not be broken, or because things have been
broken by totally removing the scripts instead of fixing them.

So, no, you can't just close this bug report without fixing it.

Please try to understand what the problem is and to test for the
problem being fixed, not for the existence of a particular file.

Perry

[Hew (hew)]

Your report states that there are problems with /etc/network/if-up.d/ntp and /etc/network/ntp-server, but these files do not exist in Intrepid, and from what I can tell, ntp works just fine. In addition, there have been many changes to ntp since this bug was reported, so this is why we ask that you please test with either Hardy or Intrepid to see if the problem still exists in the latest version.

I did not make any accusations of fault, and never suggested that this report was going to be closed before the issue has been resolved. We only wish to determine if the report still documents a valid issue in Ubuntu. Thanks again.

[Perry E. Metzger (perry-piermont)]

Hew <email address hidden> writes:
> Your report states that there are problems with /etc/network/if-up.d/ntp
> and /etc/network/ntp-server, but these files do not exist in Intrepid,

The problem isn't those files. It is the functionality. The fact that
the files no longer exist at all might in fact mean that the situation
is worse, not that it is better.

> and from what I can tell, ntp works just fine.

Okay, if you're sure there is no problem, what restarts ntp when a
machine wakes from sleep on a laptop? If it is not restarted, it is
likely not to have the correct ntp servers in use, and it will not
have the time properly synchronized.

Perry
--
Perry E. Metzger <email address hidden>

[Hew (hew)]

Thank you for your bug report. To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/community/conduct/ . Bug reports are handled by humans, the majority of whom are volunteers, so please bear this in mind.

I noted that the files you mentioned a year ago don't exist in the development version of Ubuntu, which seemed to be the core of your report. You are the sole reporter of this bug, and you are experiencing the issue, not me. I do not have a laptop, and I'm not about to go testing every open bug, even if that were possible.

It's not helpful to say the situation "might" be worse as that is just speculation on your part. I have said ntp works for me. The way we find out whether it is still an issue is for you to test if it still applies to the latest version. That way, we can either marked it as fixed, or proceed with triaging the issue and work towards a fix.

[Hew (hew)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[Perry E. Metzger (perry-piermont)]

Hew McLachlan <email address hidden> writes:
> We are closing this bug report because it lacks the information we need
> to investigate the problem, as described in the previous comments.

I don't see what you are talking about. The information is all there.

> Please reopen it if you can give us the missing information,

I'm reopening it now. There is no more "missing information" needed.

And may I say that closing bug reports without actually paying
attention to them is not socially responsible.

Perry

[Hew (hew)]

1) What version of Ubuntu was the bug reported on? Feisty?

2) Have you tested using the latest release of Ubuntu, Hardy Heron? This has a newer version of ntp, which may have solved your problem.

3) Your bug description states that the solution is to remove certain lines from certain files, but these files do not exist in the latest version of ntp. Again, please test with the latest version of Ubuntu, and let us know which files and which lines of code are at fault (if any). You can do this by updating the bug description.

[Perry E. Metzger (perry-piermont)]

Pardon my frustration here. I feel as though I'm talking to a clerk at
the DMV who is insisting that my paperwork isn't in order. It is
starting to make me write in a manner that is perhaps more angry than
is appropriate, but it feels like I'm talking to a wall. The goal here
should not be to close bug reports without understanding them. The
goal should be to fix the problem, which is simple and
straightforward.

Hew McLachlan <email address hidden> writes:
> 1) What version of Ubuntu was the bug reported on? Feisty?
>
> 2) Have you tested using the latest release of Ubuntu, Hardy Heron? This
> has a newer version of ntp, which may have solved your problem.

It doesn't solve it. I've already explained that earlier in the bug
report. If you had read the bug report and understood how ntpd works
this would not be something you would be asking.

> 3) Your bug description states that the solution is to remove certain
> lines from certain files, but these files do not exist in the latest
> version of ntp.

Yes, I know that. The files are scripts that are executed when the
system comes out of sleep or hibernate. They can be set to restart
ntpd which is the the appropriate action. By removing those files the
situation has been made worse rather than better -- the bug is not
gone simply because the scripts have been entirely removed rather than
simply rendered useless as they were before.

Restoring them with appropriate settings so ntpd restarts when a
machine comes out of sleep is the correct thing to do.

To repeat, the issue is that ntpd is not a program that "understands"
the idea of a machine, like a laptop, hibernating for some period of
time and then re-appearing on an entirely different network. Simply
restarting the daemon will cause it to behave correctly, but if the
same instance keeps running it will misbehave after reboot. This is
not a bug in ntpd -- ntpd is not built or designed for mobility and
indeed probably should not be altered for mobility. Just adding
scripts to restart it is fine. This will take five minutes for
a skilled developer, perhaps less.

> Again, please test with the latest version of Ubuntu,

I'm not an imbecile. Please stop treating me like one.

If someone wants to fix this, and understands the problem, it will
take about five minutes to put appropriate files into the appropriate
directories to restart ntpd when a machine comes out of sleep or
hibernate.

> Status: New => Incomplete

The bug report is fine. The problem is that the people reading it are
insufficiently technically skilled to understand what the issue
is. As I said, this will take all of five minutes to fix if someone
actually wants to.

I'm re-setting the status, as the bug report is most certainly *not*
incomplete.

Perry
--
Perry E. Metzger <email address hidden>

[nine (niin-deactivatedaccount-deactivatedaccount)]

The problem is present on:
- dapper: yes
- feisty: yes
- gutsy: no
- hardy: no
- intrepid: no

[Perry E. Metzger (perry-piermont)]

mouz <email address hidden> writes:
> The problem is present on:
> - dapper: yes
> - feisty: yes
> - gutsy: no
> - hardy: no
> - intrepid: no

What do you mean by "the problem is not present" -- what restarts ntpd
on gutsy or hardy? I still had this issue on Hardy when I last
checked -- I manually installed scripts so that when the network
changes ntp reinitializes. Can you tell me how you claim this happens
on hardy and intrepid without scripts?

Perry

[nine (niin-deactivatedaccount-deactivatedaccount)]

By 'the problem is not present' I mean the following:
- prepare a KVM guest with the wanted release
- install the ntp package on the guest
- set the clock a minute backwards on the guest
- force the network to change using the DHCP server on the KVM host
- observe ntpd listening on the new address (can take a few minutes)
- observe the time being synchronized

As to 'what restarts ntpd on gutsy or hardy': I did not look into that. I just found that synchronization is working after changing networks with a roaming system.

I'm sorry if it is different on your system, because in that case I obviously did not reproduce the problem.

[Perry E. Metzger (perry-piermont)]

mouz <email address hidden> writes:
> By 'the problem is not present' I mean the following:
> - prepare a KVM guest with the wanted release
> - install the ntp package on the guest
> - set the clock a minute backwards on the guest
> - force the network to change using the DHCP server on the KVM host
> - observe ntpd listening on the new address (can take a few minutes)
> - observe the time being synchronized

The ntp daemon will not learn that it is supposed to aim at different
NTP servers, so it doesn't matter that it is listening on the new
address. I do not observe the time re-synchronizing itself under these
circumstances. In fact, I observe it getting significantly off, which
is quite irritating and the reason I figured out there was a problem
in the first place.

Perry
--
Perry E. Metzger <email address hidden>

[Steve Langasek (vorlon)]

Hi Perry,

I'm unclear about the meaning of your last message. How is ntp being told to aim at different NTP servers if you /do/ restart it? The default, static configuration shipped with the ntp package always points to ntp.ubuntu.com; how do you have ntp configured such that restarting the process makes a difference in where it's syncing to?

[Perry E. Metzger (perry-piermont)]

Steve Langasek <email address hidden> writes:
> I'm unclear about the meaning of your last message. How is ntp being
> told to aim at different NTP servers if you /do/ restart it? The
> default, static configuration shipped with the ntp package always points
> to ntp.ubuntu.com; how do you have ntp configured such that restarting
> the process makes a difference in where it's syncing to?

As just one obvious answer, consider dhcp getting a new ntp server --
you do realize that dhcp changes your configured ntp servers, right? --
although it appears this has gone on so long that the dhcp exit hooks
from Jaunty now seem restart the ntp server (as you would know if you
looked into this.)

Consider also that ntpd did not traditionally notice that interfaces had
come and gone and thus would not have any ability to talk to the ntp
server if it was not restarted, although again, the ntpd shipped with
Jaunty does this correctly.

This and more is explained well enough in the bug report for someone who
understands the underlying problem.

Anyway, all of this remains an issue on Hardy and possibly on Intrepd,
but as I no longer run any such boxes I no longer care. It might still
be an issue on Jaunty for some corner cases but I haven't been paying
attention -- Jaunty is too new, and given how long it has been I haven't
even looked at all the scripts currently involved -- nothing quite like
having a bug report ignored for this long.

Perry
--
Perry E. Metzger <email address hidden>

[Perry E. Metzger (perry-piermont)]

At this point I'm unsubscribing from the bug report. I no longer know, or care, if the problem is still extant. Maybe it is and maybe it isn't, but after a couple of years of the bug living in limbo I've ceased to care, and I'm no longer running an Ubuntu laptop.

[Hew (hew)]

Closing as the bug has not been reported since Feisty.