Is Pakon a spyware?

Hi,

I have a 10TB NAS and when (quite often) Pakon starts, it does heavy disk usage (sounds like scanning through the whole big disk) for long-long minutes. Pakon is also then the top cpu user, but is only ~5%:

PID PPID USER STAT VSZ %VSZ %CPU COMMAND
6828 6824 root D 11436 1% 5% /usr/bin/python3 /usr/libexec/pakon-light/archive.py
3446 1 root S 60316 3% 1% {Suricata-Main} /usr/bin/suricata -c /etc/suricata-pakon/suricata.yaml --pidfile /var/run/suricata/sur
3549 3063 root S 25888 1% 0% {foris-controlle} /usr/bin/python3.6 /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller
23429 2 root SW 0 0% 0% [kworker/u4:2]

But CPU usage is not the major issue but the disk. I dont understand what could take so long for pakon, since its whole directory very tiny:

du -h /srv/pakon/

20.1M /srv/pakon/

AFAIK Pakon should just create some summarizing traffic statistic from memory from time to time.
Since its directory is very small, I dont know wtf it is doing, unless it is a spyware.

i think it is just some heavy sqlite operations on it’s db, but if you are paranoid you could install strace and monitor what is is doing.

sure, but if all its data is so small, what what kind of sql operation could it be that spinning the disk so hard? Shouldnt it just work from memory? all traffic should be stored in memory (max 2GB) and when it is full write it to disk, but actually just some summarized stripped down data.


Inspect the source code; it is written in python. A 10 GB magnetic disk hard drive can make noise for other reasons.
It is absolutely not spyware, but something simpler. From the page, which clarifies its operation (https://doc.turris.cz/doc/en/howto/pakon), do not show any phase that can heavily use the disc, as you also suppose. The problem must be elsewhere.

1 Like

This can be a problem, because it is related to suricata https://suricata-ids.org/, from which Pakon takes the information and which inspects the data flow. Suricata can achieve high CPU usage during the most intense flows with very wide bandwidth. Pakon in and of itself is very light.

how can I be sure? the problem is that, AFAIK there is no iotop package available in Turris repos, which could be the best program to find out this. So what is the best way to find it out on Turris?

Unfortunately it does not work on Turris, however I could find this solution:
Using Htop, properly configured:

image

I will try this next time, I have high disk io

https://lxadm.com/Simple_filesystem_read/write_tracing_with_/proc/sys/vm/block_dump

I mean I have tried it but does not work.

First of all there is no /var/log/syslog on Turris but /var/log/messages, but I dont get any info there either when I have disk activity after “echo 1 > /proc/sys/vm/block_dump”.

But htop works great and beautiful. I am looking forward to that unexpectred high disk activity and will report back what it was.

I agree with you. With the second method Is Pakon a spyware? - #9 by lucenera - Software - Turris forum, that is via dmesg, it should work. But surely htop is more intuitive, beautiful and powerful.
Let me know if you find anything interesting. I guess Pakon has nothing to do with it. But I could be wrong.

well, yes, dmesg displays it, but it does not seem to have any option to show things realtime (like -f with tail), at least the stripped down version in openwrt/turris, which has much fewer options than the one in debian/ubuntu. I could kind of circumvent it with “watch -n 1 dmseg”, but it only shows kworkers, which is not too helpful. Htop showed nfsd which is helpful.
But btw, I was wondering why tailing /var/log/messages is (not) the same output than of dmesg?

https://explainshell.com/explain/1/logread

/var/log/messages shows the messages of the system, that is of the operating environment; it is the same as giving the logread command (part of BusyBox).
dmesg shows kernel messages.
But in the end did you understand if Pakon is spyware?

in the end dmesg was also useful, since I can see exact accessed file names and it seems to me now, that it is was not Pakon but Nextcloud, which makes a bit more sense. Thanks for the inputs.

Well, I can report back now. It was indeed pakon archiver, and I have no clue what does it take for so long:

It is not indicative. I see that nfsd has a higher use, but still irrelevant. In reality Pakon cannot do more than what is written in its code. It is not spyware.