OPNsense Forum
International Forums => German - Deutsch => Topic started by: Zeitkind on October 10, 2015, 08:13:23 pm
-
Auszug aus dem system.log resp. das Ende davon..
Oct 7 13:37:51 gateway ftp-proxy[50432]: accept failed: Too many open files
Oct 7 13:37:51 gateway ftp-proxy[50432]: accept failed: Too many open files
Oct 7 13:37:51 gateway ftp-proxy[50432]: accept failed: Too many open files
Oct 7 13:37:51 gateway ftp-proxy[50432]: accept failed: Too many open files
Oct 7 13:37:51 gateway ftp-proxy[50432]: accept failed: Too many open files
Oct 7 13:37:51 gateway ftp-proxy[50432]: accept failed: Too many open files
Oct 7 13:37:51 gateway ftp-proxy[50432]: accept failed: Too many open files
Oct 7 13:37:51 gateway ftp-proxy[50432]: accept failed: Too many open files
Oct 7 13:37:51 gateway ftp-proxy[50432]: accept failed: Too many open files
Oct 7 13:37:51 gateway ftp-proxy[50432]: CLO???
Danach (3 Tage..) nichts mehr.
root@gateway:~ # sysctl -a kern.maxfiles
kern.maxfiles: 31434
Hmmm.. Hab zwar schon ein paar Sachen laufen (proxy, captiveportal usw.), aber 31k scheinen nicht zu reichen. Entweder ist das ein Bug(?) oder ich bin mit
root@gateway:~ # sysctl -w kern.maxfiles=250000
kern.maxfiles: 31434 -> 250000
erst mal auf der sichereren Seite, ma guggn. Jemand ähnliche Erfahrungen? Hab jetzt erst mal einen neuen Eintrag bei den System tunables gemacht.
-
Hallo Zeitkind,
das hört sich nach einem Ressourcen-Leck an bei stärkerer Benutzung des ftp-proxy. Ist das der squid FTP-Proxy oder builtin (klingt nach builtin)? Einfach mal den jeweils anderen ausprobieren, vielleicht hilft es.
Grüße Franco
-
Hmm.. jo, der interne heißt wohl auch genau so.
Hab allerdings dabei festgestellt, daß die Logdateien sich nicht mehr verändern..
root@gateway:/var/log # ls -ahl
total 9928
drwxr-xr-x 7 root wheel 1.0K Oct 11 03:01 .
drwxr-xr-x 27 root wheel 512B Sep 9 22:39 ..
-rw-r--r-- 1 root wheel 253B Aug 14 17:59 apcupsd.events
-rw------- 1 root wheel 500K Oct 12 01:36 dhcpd.log
-rw------- 1 root wheel 9.8K Oct 11 03:01 dmesg.today
-rw------- 1 root wheel 9.8K Oct 10 03:01 dmesg.yesterday
-rw------- 1 root wheel 500K Oct 12 01:37 filter.log
-rw------- 1 root wheel 500K Oct 12 01:36 gateways.log
drwxr-xr-x 2 root wheel 512B Jul 23 13:47 installer
-rw------- 1 root wheel 199B Oct 11 03:01 ipfw.today
-rw------- 1 root wheel 199B Oct 10 03:01 ipfw.yesterday
-rw------- 1 root wheel 500K Oct 12 01:36 ipsec.log
-rw------- 1 root wheel 500K Oct 12 01:36 l2tps.log
-rw-r----- 1 root wheel 0B Oct 12 01:35 lastlog
drwx------ 2 www www 512B Sep 12 00:05 lighttpd
-rw------- 1 root wheel 500K Jul 23 13:35 lighttpd.log
-rw------- 1 root wheel 155B Aug 16 03:01 mount.today
-rw------- 1 root wheel 119B Jul 24 03:01 mount.yesterday
drwxr-xr-x 2 root wheel 512B Jul 23 13:54 ntp
-rw------- 1 root wheel 500K Oct 12 01:36 ntpd.log
-rw------- 1 root wheel 500K Oct 12 01:37 openvpn.log
-rw------- 1 root wheel 4.1K Oct 11 03:01 pf.today
-rw------- 1 root wheel 4.2K Oct 10 03:01 pf.yesterday
-rw------- 1 root wheel 500K Jul 23 13:35 poes.log
-rw------- 1 root wheel 500K Oct 12 01:37 portalauth.log
-rw------- 1 root wheel 500K Jul 23 13:35 ppps.log
-rw------- 1 root wheel 500K Oct 12 01:36 pptps.log
-rw------- 1 root wheel 500K Jul 23 13:35 relayd.log
-rw------- 1 root wheel 500K Oct 12 01:36 resolver.log
-rw------- 1 root wheel 500K Oct 12 01:36 routing.log
-rw------- 1 root wheel 2.9K Oct 2 03:01 setuid.today
-rw------- 1 root wheel 2.9K Sep 15 03:01 setuid.yesterday
drwxr-x--- 2 squid squid 512B Oct 9 10:37 squid
drwx------ 2 root wheel 512B Oct 9 10:30 suricata
-rw------- 1 root wheel 500K Oct 12 01:37 system.log
-rw------- 1 root wheel 29K Oct 12 01:36 userlog
-rw-r--r-- 1 root wheel 394B Oct 12 01:37 utx.lastlogin
-rw-r--r-- 1 root wheel 3.1K Oct 12 01:37 utx.log
-rw------- 1 root wheel 500K Aug 26 17:13 vpn.log
-rw------- 1 root wheel 500K Jul 23 13:35 wireless.log
Viele auf 500k und werden nicht mehr angefaßt - auch nach einen Neustart. Da hängt wohl irgendwo das FreeBSD-Pendant zu logrotate? Und wo steht das 500k-Limit? Bin grade etwas FreeBSD-ratlos.. ^^
-
Alle Logs verwenden clog, eine binäre zirkuläre Variante des Logging, dh. es gibt kein rotate sondern die ältesten Einträge werden überschrieben. Für squid und suricata hatten wir das wieder auf Standards zurückgesetzt, der Rest vom System sollte einmal umgestellt werden. :)
-
Hmmm.. es kommt halt nichts neues rein.
Ein ps ax gibt als relevantes
7604 - Ss 0:15.20 /usr/local/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f /var/etc/syslog.conf
21373 - S 0:01.54 (logfile-daemon) /var/log/squid/access.log (log_file_daemon)
clog ist zwar vorhanden
root@gateway:/etc # which clog
/usr/local/sbin/clog
aber läuft nicht und ich finde auch keinen Hinweis darauf, wo oder wie er starten sollte.
-
syslogd kann und tut clog-format schreiben wenn das so angegeben ist in der Konfiguration, clog selbst ist nur zum lesen:
# clog /var/log/system.log
-
OK..
root@gateway:/var/log # clog /var/log/system.log
Segmentation fault (core dumped)
Dann ist das wohl Arbeitsverweigerung.. :D
Gut, bei den anderen Logs scheint es zu gehen. Werde später das system.log mal löschen und nen Neustart machen. Bin mir noch nicht sicher, ob ich diese rotierenden Logs mag.. hmm..
-
Wir mögen sie auch nicht. :D
Da ist wohl was im System log verklemmt. Du kannst das Log leeren über die GUI Diagnostics -> System Log -> System -> Clear Log oder so. Eine gelöschte/leere Datei ist nicht gut.
-
Naja, bin gewohnt nach rm irgendein.log ein touch irgendein.log zu machen. Aber das mag clog wohl gar nicht -> segfault. Uiui.. sollte man doch eigentlich abfangen..
Na gut, jetzt mal schauen, was der ftp-proxy treibt. Sollte eigentlich kaum was zu tun haben. Wobei.. wenn hier einige Debians Updates fahren.. hmm.. ma guggn.