Where are iftop, iotop, nethogs and friends?

Where are iftop, iotop, nethogs and friends?

opkg doesn’t know any of them. How should I use the router without them?

Did you issue opkg update first?

Here I can see:

root@maru:~# opkg list | grep ift
iftop - 1.0pre2-2 - iftop does for network usage what top(1) does for CPU usage. It listens to network traffic on a named interface and displays a  table of current bandwidth usage by pairs of hosts. Handy for  answering the question 'why is our ADSL link so slow?'.

Nethogs and iotop are missing, however.

Sadly they don’t even exist in upstream OpenWRT.
Here they decided against it because it adds additional kernel dependencies and so requires more space.

But I would realy like to see it for my TO :smile:

Ah, thanks, always forget about opkg update :slight_smile:

I would also very like to have iotop on turris. Anyone knows how to get it, or know a good alternative. I would need something that show io usage app level, not just in bulk like iostat.

It was easier than I thought.

  1. I grabbed a newest zipped snapshot from here: https://repo.or.cz/iotop.git
  2. Unzipped
  3. ./setup.py install

iotop installed

1 Like

@sik0vny Great! If it is so simple, could we ask @turris-admin to make a package for it?

Take a look here:

iotop won’t be present in OpenWrt.

@Pepe Not being present in OpenWRT doesn’t mean it can’t be present in TurrisOS :slight_smile: It really is just about cloning a single package and running setup.py, so there shouldn’t be any kernel configs needed to be changed on Turris.

It won’t be present even in Turris OS. That’s what I wanted to say.

Our Turris OS packages feed, which we provide in Turris OS 4.x and higher it has usually just specific packages for Turris routers such Updater, reForis/reForis, and so on. There are some leftovers and they will be sent to upstream in some time. Take a look at branches master/develop.

In turris-build repository, there are patches and changes to userspace configuration and it contains patches for backported packages, which were accepted to master branch of packages feed, but they were not included in OpenWrt 19.07.

If you want to have any package included in OpenWrt, send it to upstream first. Then it can be backported in some conditions as a patch in turris-build repository. If it is going to be in upstream, nice! We will have in as soon as it is in included in openwrt-19.07, which is being used currently in HBT-HBK-HBL branches. If it is only in master branch, then it is going to be included in the HBD branch.

So basically you’re saying you don’t want to maintain packages not related to TurrisOS? That’s reasonable. On the other hand, many people here on forum expressed the need to monitor what is writing to their eMMCs, and iotop seems like the best solution to this problem. You’ll have to decide whether this user need is important to you or not.

And I didn’t understand the last paragraph of your response (at least in context of iotop). There already is the PR to add iotop to openwrt. Do you want something more (i.e. a renewed PR)?

There were a few tries after the mentioned PR was closed, but all of them were not accepted due to reasons in the first pull request. Yeah, try to join the discussion there and convince them to re-think it or create a new one PR, which adds it and do it how it should be and provide feedback from that PR. The package itself is not must have neither depend on any specific our packages, so there isn’t any reason to bypass OpenWrt decision.

I see now that the required kernel flags for iotop are only present in TOS 3.x. On TOS 5.x, the are off. This affects not only iotop, but also htop (which has disk activity columns). Is there a chance we could get the required flags turned on in 5.x?

1 Like

These kernel options necessary for disk activity in htop are indeed not enabled and shows no perm.

These options are disabled for generic platform and it might be enabled for individual targets.

Config IO_ACCOUNTING depends on TASK_XACCT and config TASK_DELAY_ACCT depends on TASKSTATS, both of it are not set.

You should ask first upstream to enable it at least for mvebu platform which Turris Omnia and Turris MOX uses. This issue is in upstream as well.

I am not saying that we won’t enable it, but we try to consider it.

@Pepe is it possible that you or somebody from turris team would make the upstream issue? I don’t really feel like the best person for doing that. I’m much more an ubuntu guy than openwrt and I only understand it little.

@paja is working on this one.


Could you please reconsider? I would need to run htop in order to find what keep writing to my eMMC, as discussed here.
Please have a look.
thanks alot

Is that process publicly traceable, could not find something related in TOS Gitlab or OpenWrt Git?

Thanks, :+1: added on Github. I suggest the other commenters doing the same.