Issues with package from Debian Bookworm backprots
przemeksw opened this issue · 16 comments
Version: 1.2.6
System - debian 12.4
Hi.
After starting fastnetmon using "service fastnetmon start" I wait for a very long time.
journalctl -xe - says that pid cannot be created in the specified path - even though the access rights are there, because fastnetmon is run as root.
Please let me know how to improve it
root@ddos:/run# service fastnetmon status
× fastnetmon.service - FastNetMon - DoS/DDoS analyzer with sFlow/Netflow/mirror support
Loaded: loaded (/lib/systemd/system/fastnetmon.service; enabled; preset: enabled)
Active: failed (Result: timeout) since Sun 2024-01-07 22:53:50 CET; 1min 32s ago
Duration: 9.789s
Docs: man:fastnetmon(8)
Process: 3015 ExecStart=/usr/sbin/fastnetmon --daemonize (code=exited, status=0/SUCCESS)
CPU: 1.852s
Jan 07 22:52:20 ddos systemd[1]: Starting fastnetmon.service - FastNetMon - DoS/DDoS analyzer with sFlow/Netflow/mirror support...
Jan 07 22:52:20 ddos fastnetmon[3015]: We will run in daemonized mode
Jan 07 22:52:20 ddos systemd[1]: fastnetmon.service: Can't open PID file /run/fastnetmon.pid (yet?) after start: No such file or directory
Jan 07 22:53:50 ddos systemd[1]: fastnetmon.service: start operation timed out. Terminating.
Jan 07 22:53:50 ddos systemd[1]: fastnetmon.service: Failed with result 'timeout'.
Jan 07 22:53:50 ddos systemd[1]: Failed to start fastnetmon.service - FastNetMon - DoS/DDoS analyzer with sFlow/Netflow/mirror support.
Jan 07 22:53:51 ddos systemd[1]: fastnetmon.service: Consumed 1.852s CPU time.
I have a /20 monitoring network - so it's not that big. The configuration file is original - without any modifications. The process itself is starting - as you write - but I prefer it to be correct
Jan 07 23:11:38 ddos fastnetmon[3332]: We will run in daemonized mode
Jan 07 23:11:38 ddos systemd[1]: fastnetmon.service: Can't open PID file /run/fastnetmon.pid (yet?) after start: No such file or directory
Jan 07 23:13:08 ddos systemd[1]: fastnetmon.service: start operation timed out. Terminating.
Jan 07 23:13:08 ddos systemd[1]: fastnetmon.service: Failed with result 'timeout'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit fastnetmon.service has entered the 'failed' state with result 'timeout'.
Jan 07 23:13:08 ddos systemd[1]: Failed to start fastnetmon.service - FastNetMon - DoS/DDoS analyzer with sFlow/Netflow/mirror support.
░░ Subject: A start job for unit fastnetmon.service has failed
2024-01-07 22:58:51,538 [ERROR] Could not create pid file, please check permissions: /run/fastneton/fastnetmon.pid
2024-01-07 22:59:00,449 [INFO] Logger initialized!
2024-01-07 22:59:00,450 [INFO] ExaBGP support initialized correctly
2024-01-07 22:59:00,450 [INFO] We read global ban settings: Configuration params:
We call ban script: yes
We call ban script for IPv6: no
Packets per second: 29000
Mbps per second: 1100
Flows per second: 20000
2024-01-07 22:59:00,450 [ERROR] Could not create pid file, please check permissions: /run/fastneton/fastnetmon.pid
2024-01-07 22:59:09,823 [INFO] Logger initialized!
2024-01-07 22:59:09,824 [INFO] ExaBGP support initialized correctly
2024-01-07 22:59:09,824 [INFO] We read global ban settings: Configuration params:
the problem is that if pid is not created, systemd automatically restarts the daemon. - I started it manually and it works now, but it doesn't change the fact that something is wrong.
I have no idea why it behaves this way. Other applications including exabgp create pids in this location without any problems.
I use backports, the official Bookworm repo is the older version 1.2.4-2
Thank you for bug report. It's clearly bug in upstream Sid / Bookworm backports package and I'll share this issue with our maintainer.
You can manually fix it by making these adjustments bffdec7 for /lib/systemd/system/fastnetmon.service
Then you need to reload systemd configuration:
sudo systemctl daemon-reload
And then restart FastNetMon:
sudo systemctl restart fastnetmon
Reported to upstream.
Awesome. Sorry about this issue. We upgraded to 1.2.6 so easily that did not even check if everything is running smooth
We added backports checking for CI and it immediately picked up issue.
Issue was should be fixed in upstream.