Bug #8620
closedarpwatch database page is not accessible
0%
Description
On CE-2.4.3-p1 I am not able to open https://172.21.41.148/pkg_edit.php?xml=arpwatch.xml - getting 504
from upstream, client: 172.21.41.249, server: , request: "GET /arpwatch_database.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "172.21.41.148", referrer: "https://172.21.41.148/pkg_edit.php?xml=arpwatch.xml"
Updated by Jim Pingle about 6 years ago
- Project changed from pfSense to pfSense Packages
- Category changed from Package System to arpwatch
- Target version deleted (
2.4.4)
Updated by Cino . about 6 years ago
The issue I have with arpwatch is different but I'm pretty sure they are related. After a day or two of arpwatch running, the process becomes unresponsive. The database page becomes inaccessible. You can't stop the service, kill -9 arpwatch, killall arpwatch seem to have no effect. Due to process becoming unresponsive when rebooting pfsense; the reboot hangs and pfsense needs to be manually powered off and back on again.
As a workaround to this, I manually uninstalled the arpwatch binaries using the pkg command. I then installed arpwatch from the main FreeBSD repository http://pkg.freebsd.org/freebsd:11:x86:64/latest/All/arpwatch-2.1.a15_10.txz. The package between the two repositories are the same name, but I noticed there is a difference in file size. 1 or 2KBs.
Updated by Sven L about 6 years ago
Cino . wrote:
The issue I have with arpwatch is different but I'm pretty sure they are related. After a day or two of arpwatch running, the process becomes unresponsive. The database page becomes inaccessible. You can't stop the service, kill -9 arpwatch, killall arpwatch seem to have no effect. Due to process becoming unresponsive when rebooting pfsense; the reboot hangs and pfsense needs to be manually powered off and back on again.
I experienced exactly the same. In my case after some time running arpwatch my whole pfsense box hung up, and only a forced restart fixed it. Also the email notifications dont work correct - every notification gets send out twice.
I've heard from other users that known devices wont get saved after a pfsense restart, the settings dont make a difference.
Updated by Cino . about 6 years ago
Sven L wrote:
I experienced exactly the same. In my case after some time running arpwatch my whole pfsense box hung up, and only a forced restart fixed it. Also the email notifications dont work correct - every notification gets send out twice.
I've heard from other users that known devices wont get saved after a pfsense restart, the settings dont make a difference.
I've experienced the same email notification issue too. What I found, arpwatch has two processes running for each interface its watching. Looks like when pfsense boots up, its starting arpwatch twice. I haven't found what is causing it but I added a startup script to stop than to start arpwatch again on bootup as a workaround
Updated by Dave Bergman about 6 years ago
I'm having the same problems. Woke up this morning to find all devices that have a static IP set were off line and I could not access the Web GUI. The only way to get pfsense running was a hard reset. All through the day I could see devices going offline as there leases ran out.
Updated by DL Ford about 6 years ago
I am also experiencing this. My best guess is that Arpwatch is starting itself at boot, then pfSense is starting Arpwatch again after that (or pfSense starts it first? I'm not sure).
In addition to what others have mentioned, I have noticed these facts:
1) After installing Arpwatch everything works fine, there is one instance of Arpwatch running per configured interface.
2) After a reboot, trouble starts, two instances of Arpwatch running per interface.
3) After configuring Arpwatch, if you disable it in the pfSense webconfigurator, and then reboot, Arpwatch works as expected, one instance running per interface, no repeat emails for existing hosts, you can view the database from the webconfigurator and it does get updated by Arpwatch. The only downside to this is that it doesn't show up in the pfSense webconfigurator as a running service, but it is in fact running and working correctly at this point.
I would suggest to others in the meantime to install and configure Arpwatch from the webconfigurator, then uncheck "Enable Arpwatch", click save, and reboot. That is the state my system is in at this point, I will report here if I see any issues arise from running it this way. I would also suggest anyone doing this keep an eye on this thread, because when this issue gets fixed you'll need to enable Arpwatch again in the webconfigurator.
Updated by Mathias Möller about 6 years ago
I have exactly the same problems. The actual workaround is not to enable arpwatch, so it will be automaticly startet on next bootup.
Updated by Sven L almost 6 years ago
Its been two months now.. are there any news?
Updated by Dallas Haselhorst almost 6 years ago
I'm interested in a fix for this as well. On 2.4.3-p1 I have the same issues -- multiple emails and nothing in the database. I haven't seen the unresponsive interface issue because I removed the package and verified the processes stopped as soon as I discovered the other problems and learned that was was a possible side effect. Prior to removing the package, I checked and there were two identical processes (same network, same email) running.
Updated by Jim Pingle almost 6 years ago
- Status changed from New to Feedback
- Assignee set to Jim Pingle
Should be improved by https://github.com/pfsense/FreeBSD-ports/commit/aa78e490fe92d5640a742bbe77012a5ba626b084 but the full fix requires a 2.4.4 snapshot along with arpwatch pkg version 0.1.1. Will be available whenever the next new round of snapshots is up.
Updated by Anonymous almost 6 years ago
On 2.4.4.a.20180829.1926 (gitsync'd to master) with arpwatch version 0.1.1,
Seeing one instance of arpwatch for each interface immediately after installing:
root 1740 0.0 0.6 10688 5608 - S 01:16 0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet1.dat -i vtnet1 -m user@host.local root 1995 0.0 0.6 10688 5608 - S 01:16 0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet0.dat -i vtnet0 -m user@host.local root 5632 0.0 0.3 6968 2820 - S 01:16 0:00.00 sh -c ps uxaww | grep arpw 2>&1 root 6245 0.0 0.2 6564 2460 - S 01:16 0:00.00 grep arpw
However, after a reboot there are two instances of arpwatch for each interface:
root 39338 0.0 0.6 10688 5640 - S 01:18 0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet1.dat -i vtnet1 -m user@host.local root 39620 0.0 0.6 10688 5612 - S 01:18 0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet0.dat -i vtnet0 -m user@host.local root 39953 0.0 0.6 10688 5624 - S 01:18 0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet1.dat -i vtnet1 -m user@host.local root 40019 0.0 0.6 10688 5640 - S 01:18 0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet0.dat -i vtnet0 -m user@host.local root 52030 0.0 0.3 6968 2808 - S 01:20 0:00.00 sh -c ps uxaww | grep arpw 2>&1 root 52147 0.0 0.2 6564 2460 - S 01:20 0:00.00 grep arpw
Updated by Vladimir Lind almost 6 years ago
Yup, seeing the same on Wed Aug 29 19:26:24 EDT 2018 with pfSense-pkg-arpwatch-0.1.1:
root 37039 0.0 0.3 6968 2596 - S 12:34 0:00.00 sh -c ps auxww | grep arpwatch 2>&1
root 37290 0.0 0.0 408 324 - R 12:34 0:00.00 grep arpwatch
root 87034 0.0 0.6 8640 5052 - S 12:08 0:00.03 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx1.dat -i vmx1 -m user@host.local
root 87553 0.0 0.6 8640 5080 - S 12:08 0:00.02 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx2.dat -i vmx2 -m user@host.local
After reboot:
root 22222 0.0 0.6 8640 5176 - S 12:44 0:00.01 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx1.dat -i vmx1 -m user@host.local
root 22586 0.0 0.6 8640 5176 - S 12:44 0:00.01 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx1.dat -i vmx1 -m user@host.local
root 22951 0.0 0.6 8640 5176 - S 12:44 0:00.01 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx2.dat -i vmx2 -m user@host.local
root 23035 0.0 0.6 8640 5176 - S 12:44 0:00.01 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx2.dat -i vmx2 -m user@host.local
root 36004 0.0 0.3 6968 2804 - S 12:44 0:00.00 sh -c ps auxww | grep arpwatch 2>&1
root 36637 0.0 0.3 6564 2468 - S 12:44 0:00.00 grep arpwatch
Database is displayed OK:
Database
OPT1 10.100.100.2 00:0c:29:33:40:84 unknown Thu Aug 30 12:23:22 2018
OPT1 10.100.100.1 00:0c:29:22:ba:8b unknown Thu Aug 30 12:23:22 2018
Updated by Jim Pingle almost 6 years ago
Looks like one line of my commit is missing, will push a correction momentarily. The package is OK, the problem is on #8850
Updated by Jim Pingle almost 6 years ago
OK to test again after a gitsync or an update to a snapshot which includes my last commit on #8850
Updated by Vladimir Lind almost 6 years ago
Gitsynced, retested - now looks good, no arpwatch duplicated processes
Updated by Jim Pingle almost 6 years ago
- Status changed from Feedback to Resolved