Where are iftop, iotop, nethogs and friends?

peci1 · May 21, 2018, 7:05pm

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

einar · May 21, 2018, 9:15pm

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.

Skywalker-11 · May 21, 2018, 9:15pm

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

peci1 · May 21, 2018, 10:26pm

Ah, thanks, always forget about opkg update

Fenevadkan · April 26, 2019, 12:36pm

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.

sik0vny · May 12, 2020, 1:37pm

It was easier than I thought.

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

iotop installed

peci1 · May 12, 2020, 6:23pm

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

Pepe · May 12, 2020, 6:44pm

Take a look here:

iotop won’t be present in OpenWrt.

peci1 · May 12, 2020, 7:06pm

@Pepe Not being present in OpenWRT doesn’t mean it can’t be present in TurrisOS 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.

Pepe · May 12, 2020, 7:12pm

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.

peci1 · May 12, 2020, 7:33pm

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)?

Pepe · May 12, 2020, 7:40pm

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.

peci1 · May 13, 2020, 12:47pm

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?

Pepe · May 13, 2020, 1:49pm

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.

github.com

openwrt/openwrt/blob/openwrt-19.07/target/linux/generic/config-4.14#L4875


CONFIG_SYSTEM_TRUSTED_KEYS=""
# CONFIG_SYSV68_PARTITION is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_SYSV_FS is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_T5403 is not set
# CONFIG_TARGET_CORE is not set
# CONFIG_TASKSTATS is not set
# CONFIG_TASKS_RCU is not set
# CONFIG_TASK_XACCT is not set
# CONFIG_TC35815 is not set
# CONFIG_TCG_ATMEL is not set
# CONFIG_TCG_CRB is not set
# CONFIG_TCG_INFINEON is not set
# CONFIG_TCG_NSC is not set
# CONFIG_TCG_ST33_I2C is not set
# CONFIG_TCG_TIS is not set
# CONFIG_TCG_TIS_I2C_ATMEL is not set
# CONFIG_TCG_TIS_I2C_INFINEON is not set
# CONFIG_TCG_TIS_I2C_NUVOTON is not set

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.

peci1 · May 13, 2020, 2:20pm

@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.

Pepe · May 13, 2020, 2:20pm

@paja is working on this one.

xsys · May 18, 2020, 2:39pm

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

anon82920800 · May 27, 2020, 4:17pm

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

Pepe · June 11, 2020, 5:12pm

peci1 · June 12, 2020, 7:05am

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