Closed Bug 1775052 Opened 3 years ago Closed 2 years ago

delay in syncing with /etc/hosts file

Categories

(Core :: Networking: DNS, defect, P2)

Product:
Core
Component:
Networking: DNS
Version:
Firefox 101
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1829904

People

(Reporter: ayrat.khalimov, Unassigned, NeedInfo)

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0

Steps to reproduce:

  1. Start with the initial setup:
    /etc/hosts contains the line
    127.0.0.1 twitter.com
    127.0.0.1 www.twitter.com

  2. Open firefox, go to twitter.com: you should see "Unable to connect" -- that is OK.

  3. Now change the file and comment out those lines, so you get:

127.0.0.1 twitter.com

127.0.0.1 www.twitter.com

  1. Try to refresh the firefox tab: you will still see the error "Unable to connect" although you should now be able to connect

  2. Wait a minute or two, and refresh the page again. Now firefox picks up the changes and loads the site as expected.

Note: this delay in picking up the changes from /etc/hosts was not present in firefox a year ago or so.

(Couldn't change the description to adhere to markdown syntax, so posting a better mardowned description here.)

Steps to reproduce:

  1. Start with the initial setup:
    /etc/hosts contains the line
    127.0.0.1 twitter.com
    127.0.0.1 www.twitter.com

  1. Open firefox, go to twitter.com: you should see "Unable to connect" -- that is OK.

  2. Now change the file and comment out those lines, so you get:

# 127.0.0.1 twitter.com
# 127.0.0.1 www.twitter.com

  1. Try to refresh the firefox tab: you will still see the error "Unable to connect" although you should now be able to connect

  2. Wait a minute or two, and refresh the page again. Now firefox picks up the changes and loads the site as expected.

Note: this delay in picking up the changes from /etc/hosts was not present in firefox a year ago or so.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Component: Widget: Gtk → Networking: DNS

Replicated with User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0

Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]

Does this also happen if you disable DoH? network.trr.mode:5 ?
If it does that means it's the platform API that's slow to respond, I don't think we can do much about that.
If it doesn't happen after disabling DoH, that means it's beacuse we only reload /etc/hosts to exclude them from DoH on network change - we could watch the file for changes instead.

Flags: needinfo?(edgul)

I tried this again with 112 on linux and observed the following in no particular order:

  1. With DOH enabled: I was unable to elicit the Unable to connect page with a page refresh (ctrl+R OR hard-refresh: shift+click reload) on twitter.com after adding the recommended lines to my /etc/hosts.

  2. With DOH enabled and the lines added to my /etc/hosts file after firefox restart: twitter failed to load.
    Commenting out the lines and refreshing the page (ctrl + R) caused immediate load of twitter.

  3. With DOH disabled, adding the lines to /etc/hosts file will only cause immediate load failure with hard refresh (shift+ctrl+R).
    Commenting out the lines has similar load failure until hard refresh. Noting here that regular reload (by button click or ctrl+R) is not enough to correctly get twitter page. Though if I don't use a hard refresh and I wait long enough (1 minute or so) then a regular refresh will be enough to get the twitter page.

This makes it seem like the page result is being cached unless we use a hard refresh.

Ayrat, do you see similar behavior with hard refresh (shift+ctrl+R or shift+reload_button_click)?

Valentin, might this be expected behavior?

Flags: needinfo?(valentin.gosu)
Flags: needinfo?(edgul)
Flags: needinfo?(ayrat.khalimov)

(In reply to Ed Guloien [:edgul] from comment #5)

I tried this again with 112 on linux and observed the following in no particular order:

  1. With DOH enabled: I was unable to elicit the Unable to connect page with a page refresh (ctrl+R OR hard-refresh: shift+click reload) on twitter.com after adding the recommended lines to my /etc/hosts.

We don't actively watch for changes of /etc/hosts - so we wouldn't pick up the changes unless a network change occurred. We might do that in bug 1829904 at some point.

  1. With DOH enabled and the lines added to my /etc/hosts file after firefox restart: twitter failed to load.
    Commenting out the lines and refreshing the page (ctrl + R) caused immediate load of twitter.

  2. With DOH disabled, adding the lines to /etc/hosts file will only cause immediate load failure with hard refresh (shift+ctrl+R).
    Commenting out the lines has similar load failure until hard refresh. Noting here that regular reload (by button click or ctrl+R) is not enough to correctly get twitter page. Though if I don't use a hard refresh and I wait long enough (1 minute or so) then a regular refresh will be enough to get the twitter page.

This makes it seem like the page result is being cached unless we use a hard refresh.

That is correct. The negative result is cached for 60 seconds - after those 60 seconds, we go to getaddrinfo. The lines in /etc/hosts are commented, so we load from the network.

Ayrat, do you see similar behavior with hard refresh (shift+ctrl+R or shift+reload_button_click)?

Valentin, might this be expected behavior?

Well, it is expected - but probably not desirable. I'll dupe this to bug 1829904 and add some info there.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Duplicate of bug: 1829904
Flags: needinfo?(valentin.gosu)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.