100% CPU Auslastung durch check_reload_state und php
-
ps ax <pid>gibt keine Informationen aus, was vermutlich daran liegt, dass die Prozesse mit der hohen Auslastung (alle, außen check_reload_status) sich nach ein paar Sekunden beenden und, wenn sie wieder erscheinen, eine andere PID besitzen.
Ich habe die pfsense box hinter einem Telekom Speedport und es scheint, als ob der Fehler immer dann auftritt, wenn der Speedport iwas macht. Ich habe auch Prozesse mit den Kommandos '/usr/local/bin/php -f /etc/rc.openvpn Speedport' und /usr/local/bin/php -f /etc/rc.dyndns.update Speedport' entdeckt. Ich habe keinen DynDNS Service oder VPN m laufen</pid>
-
Hast du denn mit dem Namen "Speedport" irgendwas definiert, dass die Dienste ausgeführt werden? Oder war das von dir ein Platzhalter für die Speedport IP?
-
Das ist kein Platzhalter und ich habe auch nichts definiert. Den Begriff Speedport hat der sich alleine geholt. Es ist halt einfach der Router, über den pfSense ins Netz gelangt
-
Hier mal die Logs```
May 17 14:42:23 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:42:23 check_reload_status: Reloading filter
May 17 14:42:44 check_reload_status: updating dyndns Speedport
May 17 14:42:44 check_reload_status: Restarting ipsec tunnels
May 17 14:42:44 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:42:44 check_reload_status: Reloading filter
May 17 14:42:46 check_reload_status: updating dyndns Speedport
May 17 14:42:46 check_reload_status: Restarting ipsec tunnels
May 17 14:42:46 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:42:46 check_reload_status: Reloading filter
May 17 14:42:56 check_reload_status: updating dyndns Speedport
May 17 14:42:56 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:43:09 check_reload_status: updating dyndns Speedport
May 17 14:43:09 check_reload_status: Restarting ipsec tunnels
May 17 14:43:09 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:43:09 check_reload_status: Reloading filter
May 17 14:43:20 check_reload_status: updating dyndns Speedport
May 17 14:43:20 check_reload_status: Restarting ipsec tunnels
May 17 14:43:20 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:43:20 check_reload_status: Reloading filter
May 17 14:43:22 check_reload_status: updating dyndns Speedport
May 17 14:43:22 check_reload_status: Restarting ipsec tunnels
May 17 14:43:22 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:43:22 check_reload_status: Reloading filter
May 17 14:43:32 check_reload_status: updating dyndns Speedport
May 17 14:43:32 check_reload_status: Restarting ipsec tunnels
May 17 14:43:32 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:43:32 check_reload_status: Reloading filter
May 17 14:43:33 check_reload_status: updating dyndns Speedport
May 17 14:43:33 check_reload_status: Restarting ipsec tunnels
May 17 14:43:33 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:43:33 check_reload_status: Reloading filter
May 17 14:43:54 check_reload_status: updating dyndns Speedport
May 17 14:43:54 check_reload_status: Restarting ipsec tunnels
May 17 14:43:54 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:43:54 check_reload_status: Reloading filter
May 17 14:44:09 check_reload_status: updating dyndns Speedport
May 17 14:44:09 check_reload_status: Restarting ipsec tunnels
May 17 14:44:09 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:44:09 check_reload_status: Reloading filter
May 17 14:44:38 php: /index.php: Successful login for user 'admin' from: 192.168.1.42
May 17 14:44:38 php: /index.php: Successful login for user 'admin' from: 192.168.1.42
May 17 14:44:48 check_reload_status: updating dyndns Speedport
May 17 14:44:48 check_reload_status: Restarting ipsec tunnels
May 17 14:44:48 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:44:48 check_reload_status: Reloading filter
May 17 14:44:54 check_reload_status: updating dyndns Speedport
May 17 14:44:54 check_reload_status: Restarting ipsec tunnels
May 17 14:44:54 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 17 14:44:54 check_reload_status: Reloading filter -
Schau mal unter
Status -> System Logs -> Gateways
ob dein Gateway ständig weggeht/wiederkommt ("alam apinger"), da werden nämlich jedesmal alle Pakete neu gestartet (auch DynDNS ["Speedport" ist wohl der Name deines WAN Gateways], tunnel etc, auch wenn nicht konfiguriert)…
Notfalls in System -> Routing dein Gateway auswählen und "editiern", dort unter "Monitor IP" eine alternative IP eingeben und sehen, ob die Verbindung damit stabiler aussieht für pfSense. Wenn das nicht hilft sollten es tatsächliche Verbindungsabbrüche vom Provider her sein...
-
Ich bekomme genau diese apinger alarm Meldungen.```
May 17 14:49:01 apinger: Starting Alarm Pinger, apinger(22427)
May 17 14:49:03 apinger: SIGHUP received, reloading configuration.
May 17 15:52:09 apinger: SIGHUP received, reloading configuration.
May 17 15:52:56 apinger: SIGHUP received, reloading configuration.
May 17 17:20:19 apinger: SIGHUP received, reloading configuration.
May 17 17:21:02 apinger: SIGHUP received, reloading configuration.
May 17 19:27:13 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 17 19:27:34 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 17 19:27:37 apinger: SIGHUP received, reloading configuration.
May 18 00:41:17 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:41:42 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:41:52 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:42:07 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:42:18 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:42:27 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:42:38 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:42:42 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:42:53 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:43:00 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:43:11 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:43:22 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:43:33 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:43:37 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:43:48 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:43:56 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:44:14 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:44:20 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:44:38 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:44:38 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:44:49 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:44:53 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:45:06 apinger: ALARM: Speedport(192.168.2.1) *** delay ***
May 18 00:45:24 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:45:24 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:45:35 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:45:41 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:45:51 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:45:53 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:46:04 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:46:13 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:46:24 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:46:36 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:46:47 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:46:51 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:47:02 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:47:11 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:47:21 apinger: ALARM: Speedport(192.168.2.1) *** down ***
May 18 00:47:22 apinger: alarm canceled: Speedport(192.168.2.1) *** down ***
May 18 00:49:02 apinger: Starting Alarm Pinger, apinger(23311)
May 18 00:49:02 apinger: SIGHUP received, reloading configuration.Was soll ich dann da für eine Monitor IP eingeben? -
Äääääh, dieser "Speedport" ist ein Router mit DHCP und vergibt lokale IP's? Und ist trotzdem ständig offline? Merkwürdig!
Du kannst mal 8.8.8.8 probieren, als monitoring IP, aber irgendwie scheint ja schon die Verbindung zu dem Speedport nicht stabil!?! Kommst du in den Speedport rein und kannst sehen, ob der öfter Verbindungsabbrüche hat oder rebootet? Kannst du die pfSense mal probeweise direkt die Internetverbindung machen lassen für eine Zeit lang, um zu sehen, ob das stabiler ist? Oder ist das so ein Pflichtrouter, aus dem man die Zugangsdaten nicht herausbekommt?
Alles Raterei, wenn man die Konfiguration nicht kennt! ;-)
-
Also der Speedport ist der Router, den wir von der Telekom bekommen haben und der als Gateway für pfSense fungiert. Der hat DHCP und vergibt auch an pfSense per DHCP eine IP Adresse. Ich konnte der pfSense router auch direkt, ohne den Speedport, mit dem Internet verbinden. Das Problem ist nur, dass wir aus Onlinebanking angewiesen sind und das Risiko einfach zu groß ist, dass pfSense im entscheidenden Moment nicht funktioniert.
Mit sieht es so aus, als ob der Speedport öfters mal Verbindungsprobleme hat, sich nach ein einigen Sekunden aber wieder fängt. Vielleicht kommt pfSense damit nicht zurecht. Immer, wenn ich die hohe CPU Auslastung feststelle, hilf immer nur ein Neustart. Danach geht es aber auch ohne Probleme.
Ich werde beim nächsten Mal mal schauen, was die Speedport Logs so sagen
-
Also ich würde der pfSense eher trauen als einer T-Kom Box, aber das muss jeder für sich selbst entscheiden :)
Da machen mit pfSense Leute ganz andere Dinge als ein bisschen Onlinebanking und stabiler ist sie normalerweise auch, kommt halt auch auf den Provider und die Leitungsverhältnisse an…
-
Also die Argumentation verstehe ich auch nicht. Einer selbst definierten und gebauten Hardware mit pfSense vertraue ich aber zu 100% mehr als jedem Provider gestellten und evtl auch noch fernkonfigurierbarem Dumpfbacken-Router vom Hersteller der meint, Sicherheit ist "EMail made in Germany"…
Wenn du den Napfrouter Speedport gar nicht brauchst, sondern ein Modem genügt und es dann auch so mit der pfSense läuft, würde ich die Variante wählen, aber gestern :)
Pfsense ist der Speedport ziemlich wumpe. Was ihr nicht egal ist, ist, dass die technische Vollbremsung eines Routers wohl häufig die Verbindung intern pausiert oder trennt, dann wieder aufbaut und daher auch ständig den DHCP kickt. Die pfSense würde ich eh nicht auf DHCP laufen lassen und wenn das ohne Speedport geht, ist das auch besser als mit, aber wenn der unbedingt davor bleiben muss (bei irgendwelchem VDSL Gefrasel muss es wohl manchmal sein), dann würde ich den unnötigen DHCP abschalten, der pfSense ne fixe IP geben und gut. Und dann fliegt ihr auch nicht ständig das Gateway ab.
Es wäre eh sinnvoller eine halbwegs gut verfügbare IP als Monitoring Gateway zu nutzen, da die pfSense hier wie gesagt feststellt, ob noch eine saubere Internetverbindung steht und dann auch Graphen/Uptime Statistiken macht. Wenn die den Speedport als Gateway hat, der ständig so halbgar wegbröselt, dreht die natürlich sinnlos am Rad, weil sie denkt, dass ständig die Internetverbindung weg ist und sie alle externen Verbindungen neu handeln und aufbauen muss. Dass dann natürlich die Kiste ständig ausgelastet ist, wundert mich nicht.
Grüße
-
@chemlud:
Also ich würde der pfSense eher trauen als einer T-Kom Box, aber das muss jeder für sich selbst entscheiden :)
Vermutlich hast du Recht, nur im Moment sieht das halt so aus, dass der Speedport fast perfekt läuft und pfSense alle paar Tage diesen Fehler hat.
Also hier ist mal der Log vom Speedport. Der fehler ist ungefähr um 12:45 aufgetreten:```
19.05.2014 12:51:34 DHCP ist aktiv: LAN MAC Adresse <00:11:2F:57:F3:42> IP-Adresse <192.168.2.108> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:51:33 DHCP ist aktiv: LAN MAC Adresse <00:11:2F:57:F3:42> IP-Adresse <192.168.2.108> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:50:21 DHCP ist aktiv: WLAN MAC Adresse <00:26:B6:33:8F:85> IP-Adresse <192.168.2.111> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:50:19 DHCP ist aktiv: WLAN MAC Adresse <00:26:B6:33:8F:85> IP-Adresse <192.168.2.111> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:50:16 DHCP ist aktiv: WLAN MAC Adresse d8:90:e8:40:91:d6 IP-Adresse <192.168.2.105> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:48:09 192.168.2.100 Anmeldung erfolgreich. (G101)
19.05.2014 12:21:24 DHCP ist aktiv: WLAN MAC Adresse <8C:3A:E3:18:73:1B> IP-Adresse <192.168.2.100> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:21:23 DHCP IP-Address-Vergabe gescheitert. (H003)
19.05.2014 12:21:19 DHCP IP-Address-Vergabe gescheitert. (H003)
19.05.2014 09:37:09 DoS(Denial of Service) Angriff UDP Loop wurde entdeckt. (FW101)
19.05.2014 07:57:08 Die Systemzeit wurde erfolgreich aktualisiert. (T101)
19.05.2014 06:44:39 DoS(Denial of Service) Angriff UDP Loop wurde entdeckt. (FW101)
19.05.2014 06:43:16 DoS(Denial of Service) Angriff TCP-SYN with data wurde entdeckt. (FW101)
19.05.2014 06:43:15 DoS(Denial of Service) Angriff TCP-SYN with data wurde entdeckt. (FW101)
19.05.2014 06:43:13 DoS(Denial of Service) Angriff TCP-SYN with data wurde entdeckt. (FW101)
19.05.2014 02:05:33 DHCP ist aktiv: LAN MAC Adresse b4:07:f9:ff:bd:cf IP-Adresse <192.168.2.101> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)</b4:07:f9:ff:bd:cf></d8:90:e8:40:91:d6> -
Die pfSense würde ich eh nicht auf DHCP laufen lassen
Also dann bei pfSense das WAN Interface auf statisch umstellen?
-
@chemlud:
Also ich würde der pfSense eher trauen als einer T-Kom Box, aber das muss jeder für sich selbst entscheiden :)
Vermutlich hast du Recht, nur im Moment sieht das halt so aus, dass der Speedport fast perfekt läuft und pfSense alle paar Tage diesen Fehler hat.
Also hier ist mal der Log vom Speedport. Der fehler ist ungefähr um 12:45 aufgetreten:```
19.05.2014 12:51:34 DHCP ist aktiv: LAN MAC Adresse <00:11:2F:57:F3:42> IP-Adresse <192.168.2.108> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:51:33 DHCP ist aktiv: LAN MAC Adresse <00:11:2F:57:F3:42> IP-Adresse <192.168.2.108> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:50:21 DHCP ist aktiv: WLAN MAC Adresse <00:26:B6:33:8F:85> IP-Adresse <192.168.2.111> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:50:19 DHCP ist aktiv: WLAN MAC Adresse <00:26:B6:33:8F:85> IP-Adresse <192.168.2.111> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:50:16 DHCP ist aktiv: WLAN MAC Adresse d8:90:e8:40:91:d6 IP-Adresse <192.168.2.105> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:48:09 192.168.2.100 Anmeldung erfolgreich. (G101)
19.05.2014 12:21:24 DHCP ist aktiv: WLAN MAC Adresse <8C:3A:E3:18:73:1B> IP-Adresse <192.168.2.100> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)
19.05.2014 12:21:23 DHCP IP-Address-Vergabe gescheitert. (H003)
19.05.2014 12:21:19 DHCP IP-Address-Vergabe gescheitert. (H003)
19.05.2014 09:37:09 DoS(Denial of Service) Angriff UDP Loop wurde entdeckt. (FW101)
19.05.2014 07:57:08 Die Systemzeit wurde erfolgreich aktualisiert. (T101)
19.05.2014 06:44:39 DoS(Denial of Service) Angriff UDP Loop wurde entdeckt. (FW101)
19.05.2014 06:43:16 DoS(Denial of Service) Angriff TCP-SYN with data wurde entdeckt. (FW101)
19.05.2014 06:43:15 DoS(Denial of Service) Angriff TCP-SYN with data wurde entdeckt. (FW101)
19.05.2014 06:43:13 DoS(Denial of Service) Angriff TCP-SYN with data wurde entdeckt. (FW101)
19.05.2014 02:05:33 DHCP ist aktiv: LAN MAC Adresse b4:07:f9:ff:bd:cf IP-Adresse <192.168.2.101> Subnetzmaske <255.255.255.0> DNS-Server <192.168.2.1> Gateway <192.168.2.1> Lease Time <1814400> (H001)</b4:07:f9:ff:bd:cf></d8:90:e8:40:91:d6>Das Problem ist aber eher die DHCP-Vergabe des Speedport und dann erst nachgeordnet hat pfSense ein Problem damit, wenn der DHCP spinnt. Tritt das Problem ohne den Speedport überhaupt auf?
-
@chemlud:
Das Problem ist aber eher die DHCP-Vergabe des Speedport und dann erst nachgeordnet hat pfSense ein Problem damit, wenn der DHCP spinnt. Tritt das Problem ohne den Speedport überhaupt auf?
Ohne Speedport hab das noch nie ausprobiert. Zum einen sind meine Eltern davon nicht so begeistert, wenn ich das alles umbaue und zum anderen ist das WLAN bei der pfsense Box noch nicht so das Wahre.
Aber so, wie ich dich verstanden habe, hilft es bei pfsense eine statische IP einzugeben, um das DHCP zu umgehen?
-
Frage an Radio Eriwan, Antwort: Im Prinzip schon! Ob der Gateway zu dem Speedport dadurch stabil wird kann ich nicht vorhersagen. Andere empfahlen schon, den Gateway-Monitor in der pfSense abzuschalten. Aber vorher würde ich es mit fixer IP probieren.
(PS: Es gibt nix schlimmeres, als alte Leutchen, die noch an die POST (Telekom) glauben… :-D )
-
Jetzt habe ich nur das Problem, dass ich mit einer statischen IP gar keine Internetverbindung hinbekomme ???
Hier mal meine Konfiguration http://imgur.com/NT1v2ht
Also ich kann mit pfSense die 8.8.8.8 und meinen PC anpingen und mit meinem PC kann ich auch die pfSense Box anpingen. Nur vom PC ins Internet geht nix.
-
"System" -> "General Setup" sind dort DNS Server gesetzt? Ansonsten: mach mal…
-
Jap, da sind welche
-
Wenn ich die Einstellung auf statisch stelle, bekomme ich, wenn ich eine Internetseite aufrufen will, keinen Fehler angezeigt, sondern der lädt einfach bis zum timeout
-
Ich habs jetzt über PPPoE laufen. Mal sehen, ob der Fehler wieder auftritt
