Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • gnome-shell gnome-shell
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 2.1k
    • Issues 2.1k
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 162
    • Merge requests 162
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • gnome-shellgnome-shell
  • Issues
  • #2774

connection to oscp-router0(1|2).gnome.org hanging in state CLOSE_WAIT

Affected version

  • OS: Arch Linux x86_64
  • Gnome Shell version: 3.36.2+7+ge4199c71-1, i.e., built from commit e4199c71
  • I'm using Wayland

Bug summary

gnome-shell keeps a socket to oscp-router01.gnome.org or oscp-router02.gnome.org open in state CLOSE_WAIT forever.

Steps to reproduce

  1. Log in
  2. Run sudo lsof -i |grep gnome-sh

What happened

See above. lsof will show something like this:

gnome-she 1220 bevan   64u  IPv4  36254      0t0  TCP bevan-thinkpad:41980->oscp-router02.gnome.org:https (CLOSE_WAIT)

By now, I found out that openshift.gnome.org resolves to the IPs of these hosts and that for example extensions.gnome.org is an alias for that. So the connection could be part of the extensions update check. But this is just a wild guess...

What did you expect to happen

The connection should actually be closed and not hang around in CLOSE_WAIT forever.

Relevant logs, screenshots, screencasts etc.

Assignee
Assign to
Time tracking