Chromium snap causes network traffic. (Duh!)

[rew]

When Chromium is running (but otherwise idle!), there is NFS traffic between my workstation and the NFS server here. On the order of 24000 packets per second. Several tens of packets, OK. several hundreds: mwah. But this is outrageous.

When strace-ing the chrome process I see:

poll([{fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}, {fd=137, events=POLLIN}], 5, 0) = 0 (Timeout)
recvmsg(31, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(31, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(32, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(32, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(32, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)

It uses poll to wait for events... and then gets informed: A timeout occurred, no filedescriptors are ready and then STILL Tries to read from fd 31 and 32. Furthermore, the process seems to specify a 0 timeout as quite often I see the poll call return in about 20-50 microseconds.

The process that is doing this shows as:

 /snap/chromium/1284/usr/lib/chromium-browser/chrome --no-default-browser-check --no-first-run --password-store

1)
Description: Ubuntu 20.04.1 LTS
Release: 20.04

2)
chromium-browser:
  Installed: 84.0.4147.105-0ubuntu0.20.04.1
  Candidate: 84.0.4147.105-0ubuntu0.20.04.1
  Version table:
 *** 84.0.4147.105-0ubuntu0.20.04.1 500
        500 http://nl.archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages
        100 /var/lib/dpkg/status
     80.0.3987.163-0ubuntu1 500
        500 http://nl.archive.ubuntu.com/ubuntu focal/universe amd64 Packages

3) I expect chromium to use little to no resources (CPU, network) when I'm not actively using it. (asking for small memory footprint is not currently realistic).

4)_ Chromium seems to do something that requires NFS traffic.

[Olivier Tilloy (osomon)]

Thanks for the report rew.
For testing purposes, could you download the google chrome installer from google.com/chrome, install it and test whether it is behaving similarly? That would be a useful data point. Thanks!

[rew (r-e-wolff)]

OK. Done. Downloaded, tested: Nope, google-chrome-stable does not show this behaviour.

[rew (r-e-wolff)]

(posting this from Chromium again, and immediately I see the network traffic ballooning. It does look a bit as if the linux "select" behaviour: modify the timeout to show time remaining is involved: It takes like 15 seconds of medium traffic before stuff is back to the original level again. My hypothesis is that "1ms" is still in the timeout field for those first 15 seconds, so the repeat rate of the triggering code is not so high. Then the timeout is reduced to zer and it goes fullblast...

[rew (r-e-wolff)]

I just measured the network trafic that chromium is causing.... It is about 23000 network packets per second.

[rew (r-e-wolff)]

(earlier this week:) To debug this further I started chromium under "strace -f -o /tmp/..." : Must be run as root. Hmm.

Today I tried something different. I used strace on ALL 33 chrome processes. Many did something every second or so, just one was in a tight loop. This is also the process that continues to use about 30% of one core.

I used "task manager" from Chrome to try to figure out what chrome would call this process itself. I expected to find "browser", but the top CPU-users according to chrome were using only about 2% of CPU time, so it is not listed on the "task manager" list. :-/

The process that is using CPU time, turns out to be the same as the one that is causing the network traffic: Just stopping that one process causes the network traffic to stop.

What I don't understand is how the calls:

poll([{fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}, {fd=41, events=POLLIN}], 5, 0) = 1 ([{fd=12, revents=POLLIN}])
recvmsg(30, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
read(12, "!", 2) = 1
write(28, "\0", 1) = 1
recvmsg(30, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(31, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(31, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(31, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}, {fd=41, events=POLLIN}], 5, 0) = 0 (Timeout)
recvmsg(30, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(30, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(31, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(31, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(31, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)

end up causing NFS traffic. It is about 50/50 that I see a timeout and "data available on fd 12"
When that data is available and read (one character) then often one character is written to fd 30 (more than 50% of the cases, but not always).

The three filedescriptors are a pipe and two sockets. I don't know how to find out where they go.

lr-x------ 1 wolff wolff 64 Feb 20 13:40 12 -> 'pipe:[42472991]'
lrwx------ 1 wolff wolff 64 Feb 20 13:40 30 -> 'socket:[42471337]'
lrwx------ 1 wolff wolff 64 Feb 20 13:40 31 -> 'socket:[42470374]'

I see 4637 poll calls each 10 seconds, 2270 read (12...) calls (49%) and 1537 (33%) writes to fd 30. With about 23000 total EAGAIN calls to recvmsg. The total of 23000 corresponds to the number of network packets in a period of 10 seconds...

So my conclusion is that

recvmsg(30, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(30, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(31, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(31, {msg_namelen=...

[rew (r-e-wolff)]

I copied the "common" directory of ~/snap/chromium to a local filesystem (1Gb ) and created a symlink to point to the local version.

When I start chromium I then get:

 mkdir: cannot create directory '/home/wolff/snap/chromium/common': File exists

and chrome refuses to start. I then restored my backup and chromium is back to the old behaviour.