network usage broken when recvbytes is 8 digits or longer

Bug #914098 reported by Will Elwood on 2012-01-10
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
byobu
Low
Unassigned

Bug Description

I noticed my network usage status disappeared recently, tracked it down to the way /proc/net/dev is parsed.

Test data:
    lo:907096306 125825857 0 0 0 0 0 0 907096306 125825857 0 0 0 0 0 0
  eth1:858630703 130597790 0 0 0 0 0 31982 1819919816 140249010 0 0 0 0 0 0
  eth0:1661706230 120880636 0 0 0 0 0 0 203288241 59658728 0 0 1 0 0 0

The current code that reads in a loop into variables is caught out by the lack of space to separate the interface and the first number (receive bytes). I've had a go at fixing it using grep, cut and awk instead. Also updated ec2_cost to match (but don't have any way to test) and removed the unused OIFS and tx1 variables in network, hope that's alright.

Will Elwood (w.elwood08) wrote :
description: updated
Dustin Kirkland  (kirkland) wrote :

Thanks for the patch.

We don't want to use grep/awk/sed here, as those shell outs are very expensive. We recently moved all of this code from using grep/awk/sed to native shell code and saw some nice performance improvements.

I'll have to find another way around.

Changed in byobu:
importance: Undecided → Low
status: New → In Progress
Dustin Kirkland  (kirkland) wrote :

Doh. I broke this in r1839. Fixing now.

Changed in byobu:
status: In Progress → Fix Committed
Changed in byobu:
status: Fix Committed → Fix Released
Will Elwood (w.elwood08) wrote :

I had a feeling the sub-shell wasn't the way to go even as I was writing it, but I had already tried adding a colon to $IFS without success. Unfortunately, 5.4 still doesn't work for me without the small change attached. My tests also show that dash doesn't remove the leading spaces like bash does, so the snippet that parses /proc/net/dev doesn't work stand-alone without `#!/bin/bash` at the top but that doesn't seem necessary for Byobu.

Hi Will, thanks for the followup!

Can you try the 5.5 release from yesterday? I actually put a better
fix for this in place. It seems to work in my testing...

Will Elwood (w.elwood08) wrote :

Hi, kudos on the quick release - I've been running 5.5 for a few hours now and it all seems fine. Agreed on the better fix, handles both cases clearly rather than hiding the workaround.

Dustin Kirkland  (kirkland) wrote :

Thanks for the followup!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers