Data collection broken at

Has anyone else seen that the data statistics for your Omnia at show very low to no data usage? I seem to have found a bug there, but it would seem to be very common if its what I think it is. Please advise if you have seen the same.

I was hitting this and the only viable fix I found was to revert ucollect’s init script back to an older version (it had been recently rewritten to use procd init). The newer init script somehow doesn’t start ucollect properly at boot. See this bug

Between this issue and the problems with haas, unfortunately the data gathering features of the router aren’t working well at present out of the box.


The same problem occurs on my Turris 1.x router :frowning:

Can you share a hot fix?

as I mentioned in I dont know how to openwrt init scripts work well enough to fix it easily. I just reverted back to the last version of /etc/init.d/ucollect that worked for me, which was the one without the recent set of changes. that bug is assigned to the developer who made the most recent changes that seem to be triggering the issue. I haven’t heard yet if the developer has reproduced the problem themselves.

1 Like

Ich habe ein ähnliches Problem. Seit dem 25.08. zeigt “Statistics”, beispielsweise “In vs. Out” nur einen Datentransfer von wenigen kB. Das kann nicht stimmen.

Bis zum 25.08 hatte ich für mich normale Werte; einige GB.


Hi, sometimes it seems like it is not working, but giving it some time to settle, it is OK:

Device Turris Omnia - rtrom01
Serial number xxxxx
Turris OS version 3.10.5
Kernel version 4.4.150-0a333a8e606ab056173befac424900d2-1
Sending of uCollect data Online (status updated 29 seconds ago)
Sending of firewall logs Online (status updated 500 seconds ago)

@jada4p That’s not the issue. For me things also look fine on the router’s about page, but it you go to, you’ll see that you get absurdly low values for data transfer per day, like this below. For all the days through 27 August, ucollect was started at router boot time using the old style init file. for 28 August, I switched to the procd init file, and only 400kb of data usage was logged, even though I was actively using my home connection all day.

@Pepe wrote back to me on this issue saying he couldn’t reproduce it, and that the bug wasn’t being looked at due to other higher priority work. However, I thought part of the value of the Turris router was the data collection off the routers, which appears to be completely broken at this point for at least everyone on this thread and likely others as well, unless someone hacks a fix as I did. @Pepe totally understand that you guys are busy and need to focus on other stuff, but isn’t reverting back to the old init script as I mentioned in ucollect flow plugin not sending data to uplink (#216) · Issues · Turris / Turris OS / Turris OS packages · GitLab an option? That would be a quick way to fix the bug for end users and hopefully wouldn’t take much time. Later on you could figure out why the procd approach didn’t work.

1 Like

I share @tonyquan’s assessment.

@kollerq or others on this thread, have you tried rolling back the ucollect init script to see if that fixes it?

I’d like to see the Turris team just do that (go back to what was working) but haven’t seen any movement in that direction.

Thanks to @tonyquan.

I have replaced the script “ucollect”. See what happens. I will report tomorrow or the day after.

@kollerq at least for me, the problem only reproduces at router first boot, so you might have to reboot after replacing the init script.

@Pepe has agreed that a future Turris OS release will roll back the init script as well.

Unfortunately, my enjoyment of the exchanged script was only of short duration.

I’m going to reinitialize the router today and then I’ll see.

@kollerq I actually think the fix was working. the way that the data collection as website works is, the graph is only completely updated once every 24 hours. at least for me, it is not until sometime the next day that all the data fills in for the day before. so you may not see all of the 4 Sept data until later in the day on 5 Sept. You can look at the “Sending of data”, “Detail” page to see if the whole 24 hours of data for 4 Sept has been processed yet. No bar for 4 Sept “Sending of data” will be shown until the entire 24 hour data set for 4 Sept is posted. this is what things look like for me for example, as you can see the 4 Sept data usage looks low compared to prior days. However I can see from “Sending of data” that only 3 Sept data processing is done, there is no green bar for 4 Sept yet. Later on on 5 Sept the green bars will appear for 4 Sept, and the in/out graph for 4 Sept will be correct in my experience.

29 Aug was messed up for me because I was testing the “broken” script that day.

Thank you very much, @tonyquan .
I will be more patient. Still, it didn’t hurt that I reinitialized the Turris Omnia. I will now work with the “broken” script until no more data is transferred and then I will replace the script and i will wait 2, 3 days. Then I report here again.

sure @kollerq BTW here is my chart for today and you can see that the 4 Sept data is now updated properly, so the older init script is working.

Code replaced in uconnect-script works fine.

Thanks for your help.

1 Like

Thanks for verifying that rollback does fix the issue. @Pepe did indicate that in Turris 3.10.6 they’ll be rolling back this script, but I’m not sure that change has been checked in yet.

1 Like