Where are iftop, iotop, nethogs and friends?

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.

2 Likes

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.

jow replied on github, ping @pepe

The TO is subjected to specification of devices with lesser hardware capabilities that are included in the same OpenWrt target class (mvbeu > cortexa9), in this case to devices with 3 MiB kernel partition space, which OpenWrt is struggling to cope with as the kernel source code keeps on growing.

In the unlikely event that OpenWrt will be enabling those kconfig flags and in case TOS developers neither enabling the flags in their toolchain one would be left to build a kernel without those restraints.

Does iotop work for you in the latest TurrisOS 5?
This solution worked for me on TOS3 but not anymore on TOS5, I got this error when trying to run it:

Traceback (most recent call last):
File “/usr/sbin/iotop”, line 10, in
from iotop.ui import main
File “/usr/lib/python3.7/site-packages/iotop/ui.py”, line 46, in
from iotop.data import find_uids, TaskStatsNetlink, ProcessList, Stats
File “/usr/lib/python3.7/site-packages/iotop/data.py”, line 51, in
vmstat_f = VmStat()
File “/usr/lib/python3.7/site-packages/iotop/vmstat.py”, line 23, in init
self.vmstat = self.read()
File “/usr/lib/python3.7/site-packages/iotop/vmstat.py”, line 40, in read
return pgpgin, pgpgout
UnboundLocalError: local variable ‘pgpgin’ referenced before assignment