Modify

Opened 8 years ago

Last modified 4 years ago

#7453 accepted defect

ntpclient gets stopped any time any interface is brought down

Reported by: dharding@… Owned by: jow
Priority: normal Milestone: Chaos Calmer 15.05
Component: packages Version: Backfire 10.03
Keywords: Cc:

Description

The hotplug script for ntpclient is written in such a way that any time an ifdown event occurs, the ntpclient program is stopped even if there is still a valid interface up.

If the ntpclient instance was associated with a specific interface, I would not expect it to be stopped until that specific interface was brought down. If it was not associated with a specific interface, the desired behavior is less clear, but it seems undesirable to stop it unconditionally. In that case, perhaps it should be stopped and then conditionally restarted if there is still an interface available for it to use.

Attachments (2)

ntpclient_hotplug.patch (3.3 KB) - added by dharding@… 8 years ago.
initial patch for improving ntpclient behavior on ifdown
netstate_clear_up.patch (492 bytes) - added by dharding@… 8 years ago.
clear the "up" state for an interface on ifdown

Download all attachments as: .zip

Change History (9)

comment:2 in reply to: ↑ 1 ; follow-up: Changed 8 years ago by dharding@…

Replying to anonymous:

Anonymous, whoever you are, I certainly hope you don't actually represent anyone in the OpenWRT project. I understand that resources are scarce, and that the developers don't have time to address every issue that is brought up. However, such an arrogant, abrasive response is in no way called for. If the bug will not be addressed without a patch, I understand, but there are much more courteous ways to say so.

My bug report was specific and pertained to what I consider to be incorrect behavior of the ntpclient script. I am sure there are much more serious issues that could be addressed within the OpenWRT project, but that does not make this one irrelevant.

I in no way demanded a fix from anyone with the OpenWRT project. In addition I explained what I thought the correct behavior might be, in case anyone might have any input with regards to the design of the fix.

It is important to recognize that users do have value, even if they can't code. Users who test and file useful bug reports are an asset to a project even if they aren't able to give a 100% solution to every problem they encounter. Responses such as yours serve only to tear down and drive away productive members of the community.

As it turns out, I am in fact a hacker and was working on a patch even before I filed this ticket. However, as with many in the Open Source world, my development happens in my spare time. I was about to leave for a week of travel and did not have time to fully test my patch. Rather than post something half-baked, I decided to wait until I got back and was able to make sure everything was working. I prefer to contribute value rather than simply going around yelling at people for no reason except to be an a.

Patch to be posted later today or tomorrow.

comment:3 in reply to: ↑ 2 Changed 8 years ago by KanjiMonster

Replying to dharding@…:

Replying to anonymous:

Anonymous, whoever you are, I certainly hope you don't actually represent anyone in the OpenWRT project. I understand that resources are scarce, and that the developers don't have time to address every issue that is brought up. However, such an arrogant, abrasive response is in no way called for. If the bug will not be addressed without a patch, I understand, but there are much more courteous ways to say so.

Let me assure you that he is just a troll and in no way represents [i]anyone[/i] in this project. Unfortunately it isn't easy to stop him from trolling without also affecting legitimate bug reports. While there are anti spam features, you can never catch it all, and especially trolls have a tendency to adapt to them.

And I understand your concern completely, I feel the very same way about it.

Regardless of that, thank you for your bug report and even taking the time creating a patch. As a warning in advance, don't be discouraged from further bug reporting/writing patches if it takes a bit of time until your patch gets reviewed/applied.

Changed 8 years ago by dharding@…

initial patch for improving ntpclient behavior on ifdown

comment:4 Changed 8 years ago by dharding@…

Thanks KanjiMonster for the encouragement. I've attached an initial patch that provides better behavior.

When the ntpclient process is actually started, the script marks which interface(s) are associated with the ntpclient process: if a specific interface was specified in the ntpclient configuration, only that interface is marked; otherwise, all interfaces that are up at the time the ntpclient process is started are marked.

When an interface is brought down, if that interface is marked, the ntpclient process is stopped and all interfaces are unmarked. The script then tries to see if it can start the ntpclient process again, in case there is another interface available that can be used.

The issue with the script as it stands is that it uses the UCI state mechanism to keep track of which interfaces are marked by setting the network.$iface.ntpclient_interface state value to 1 for each marked interface. However, there are some ordering issues with regards to the hotplug scripts getting called and the state getting reverted when an interface is brought down. As a result, the script by itself doesn't usually stop the ntpclient process when it should.

I have some patches in progress that would address this, but they touch much closer to the core operation of the OpenWRT system. I can either try to get those patches polished up, or find an alternate mechanism to store the state information needed by the ntpclient script.

Changed 8 years ago by dharding@…

clear the "up" state for an interface on ifdown

comment:5 Changed 8 years ago by dharding@…

As it turns out, most of the changes I needed were already done in r21383 (backported to Backfire in r21662). The only missing bit was making sure the 00-netstate hotplug script cleared the "up" flag on ifdown, for which I just attached a patch. With that change and the changes from r21383, my ntpclient patch should be working fine. However, if my new ntpclient script were to be installed on an older system without those changes, it might not always stop the ntpclient process when it should. If that is a serious enough issue, I can still look into trying to use some other state mechanism for recording which interfaces are marked.

comment:6 Changed 7 years ago by anonymous

Ntpclient is still stopped when for instance a vpn connection is terminated, even if wan interface (to which ntpclient is bound) remains up. Please fix this issue.

comment:7 Changed 7 years ago by jow

  • Owner changed from developers to jow
  • Status changed from new to accepted

comment:8 Changed 4 years ago by jow

  • Milestone changed from Backfire 10.03.2 to Chaos Calmer (trunk)

Milestone Backfire 10.03.2 deleted

Add Comment

Modify Ticket

Action
as accepted .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.