# Rechner ging down

## sambatasse

hallo

mein rechner war nicht mehr ansprechbar bis auf ping

konnte nur reseten

das einzige ist die logs sind damit voll 

 *Quote:*   

> syslog-ng[1844]: Error accepting AF_UNIX connection, opened connections: 100, max: 100

 

kann mir jemand nen tip geben was da schief gelaufen ist

----------

## NightDragon

Die Meldung heißt eigentlcih nur das syslog-ng 100 verbindungen hat und das Maximum (100) eben erreicht wurde. Aber deswegen dürfte sich der Rechner nicht aufhängen.

Ist das ein Syslog-Server? Hast du Syslog auf einen Port zum lauschen eingerichtet? Sendest du den Server irgendwelche Infos auf Syslog?

Evtl. wurde Syslog-ng überfordert. So eine art Overflow.

----------

## sambatasse

ick habe denn nur ganz einfach inststalliert (emerge syslog-ng )

keine ahnung wo kann ich nach sehen

und das ist da einzige in den log kommt auch von der zeit hin 

komisch selbst wenn dürft doch nicht der sever so ausgelastet sein das der apache nicht erreichbar ist

----------

## NightDragon

Naja... wenn eine Unmenge an Daten gesendet werden oder so, leicht möglich.

Die Konfig befindet sich in /etc/syslog-ng/syslog-ng.conf

Aber wenn du nie was verändert hast, hört syslog-ng eigentlich auch nicht auf eingehdene Verbindungen.

Hm. Naja... wenn er nur auf apache reagiert und sonst nichts mehr, kann ich mir auch nichts vorstellen.

Hast du versucht eine SSH Verbindung hin aufzubauen? Hat er darauf auch nicht reagiert? Oder nur auf apache nicht mehr?

----------

## sambatasse

es ging nix mehr 

kein apache

kein ssh

kein mail

kein ts

nur ping ruckelte vor sich hin

/etc/syslog-ng/syslog-ng.conf 

 *Quote:*   

> # $Header: /var/cvsroot/gentoo-x86/app-admin/syslog-ng/files/syslog-ng.conf.gentoo,v 1.4 2004/07/18 02:25:02 dragonheart Exp $
> 
> #
> 
> # Syslog-ng default configuration file for Gentoo Linux
> ...

 

----------

## NightDragon

Also die Konfig ist okay. 

Na mal abwarten. Evtl. ists nur eine einmalige Aktion.

----------

## sambatasse

ich überlege grade

wenn zu syslog mehr verbindungen aufgebaut wurden als er kann

muss doch irgendwas sein 

ich habe nix instaklliert uberhaupt schaft man mit einem system überhaupt 100 ?

----------

## dakjo

Wenn ein Dienst etwas an syslog melden will, das er tot ist und gleich das system mitreist und das dann in einer schleiffe tut? vielleicht dann

----------

## NightDragon

Hm.

Na ich hätte einafch angenommen das es eine Art DOS-Attacke auf syslog-ng war. aber wenn syslog-ng nicht hinhört kann ich mir das nicht vorstellen bzw. Ists für mich unlogisch wie ein Limit erreicht werden kann.

Ja ja, durchaus. Ein rechner schafft schon 100 Verbindungen. Es kommt immer drauf an was man unter Verbindung versteht.

Sinds die offenen Sockets? Oder sinds die Verbindungen die zu syslog-ng bestehen.

Ein Rechner kann eigentlich ohne weiteres einige Tausen Verbindungen verwalten. ob das dann auch einige Tausend syslog-ng Verbindungen sein dürfen/können, keine Ahnung. 

Aber ein Limit ist ja gerade dazu gedacht, den Server nicht zu überfordern und alles übers Limit abzulehnen.

Evtl. hat ein lokaler Dienst syslog-ng vollgemüllt.

Kann ja sein das mehr wie 100 lokale verbindungen (von z. bsp. Apache zu syslog) aufgebaut wurden und dann irgendwas sich verkeilt hat.

----------

## gentop

Nur mal so nebenbei: AF_UNIX Connections sind keine Netzwerkverbindungen, sondern UNIX-"Dateisystemverbindungen". Wenn man so will ist AF_UNIX ein Socket auf dem lokalen System. Und hier versuchen auf einen Socket (syslog) zu viele Anwendungen (oder eine ganz oft?) zuzugreifen.

//gentop

----------

## NightDragon

a ja... ist ja AF_UNIX

Vor lauter eigenne AF_INET Errors *lach* hab ich schon INET gelesen.

Hm. Ja gentop, führt sowas den zum hang up? Normalerweise doch nicht oder?

----------

## gentop

Wenn irgendeine Anwendung so viele Sockets offen hat (100) und dann auch noch eine wichtige Systemanwendung schreiben möchte, folglich nicht kann und so lange "wartet", bis sie wieder schreiben darf? Kann ich mir gut vorstellen, dass das System so lange stillstehen kann... bis wieder weitere Socketverbindungen erlaubt sind. Ausprobieren möcht ich das aber nicht  :Wink: 

//gentop

----------

## DarKRaveR

Also, AF_UNIX sind ja Unix doamin sockets, diese werden von diversen apps benutzt, bind zum beispiel für rndc, db server - generell für IPC, genauso wie named pipes eben.

Die Frage wäre daher, hast Du eventuell eine Applikation(einen Daemon) am laufen, der sehr viele Unix Domain sockets offen hat ? (Wobei das eigentlich komisch wäre, es passiert eher mal, daß nicht genug shared mem instanzen erlaubt sind, weil diese massiv genutzt werden .....)

Nehmen wir mal an, Du hast apache+php und nen SQL server, für jedes script, daß via domain socket local auf den sql server zugreift, wird ein socket verbraucht, dann könnten 100 schnell verbraucht sein, erst recht, wenn irgendwo noch nen leak ist, weil FDs nicht wieder korrekt freigegeben werden ....

Alles nur Ideen/Mutmaßungen, da ich ja das System nicht kenne ....

----------

## kurt

Hallo,

ich weiss nicht ob es helfen wird aber hier mal ein vorschlag erhöhe kernel.msgmni=128 oder auf kernel.msgmni=1024 in der /etc/sysctl.conf

##########################################

### quelle ibm.com

##Ressourcengrenzen auf Linux-Maschinen festlegen

##

##

##Auf allen Linux-Maschinen müssen Grenzen für Nachrichtenwarteschlangen festgelegt werden. Gehen Sie dazu wie folgt vor: 

##

##Ermitteln Sie die aktuelle Einstellung für die maximale Anzahl von Nachrichtenwarteschlangen, indem Sie den Befehl 

##ipcs -l

##wie folgt ausgeben: 

## # ipcs -l

##Ein Teil der Ausgabe sollte aus folgenden Informationen bestehen: 

##-----Messages: Limits -----

##max queues system wide = 128

##max size of message (bytes) = 8192

##default max size of queue (bytes) = 16384

##Wenn der Wert für den Parameter 'max queues system wide' kleiner als 128 ist, erhöhen Sie ihn, indem Sie folgenden Befehl eingeben: 

### echo 128 > /proc/sys/kernel/msgmni

##Es wird empfohlen, diesen Befehl einem Startskript hinzuzufügen, das bei jedem Neustart der Maschine ausgeführt wird, z. B. der Datei /etc/rc.d/rc. Setzen Sie den Wert für den Parameter, wenn möglich, auf 256. 

##

##(9224)

gruss

kurt

----------

## DarKRaveR

@kurt:

MsgQueues sind ein andere IPC MEchanismus, unix domain sockets zeigen sich davon unbeeindruckt .... würde ich meinen, wobei ich nicht ausschließe, daß es für Unix Domain Sockets auch Settings geben mag .....

Wobei genaugenommen alle IPC mechanismen nur shared memory und mutexes voraussetzen, sowas wie MsgQueue ist eigentlich nur ne Spezialisierung ... Unix Domain Sockets im PRinzip ebenfalls (wobei ich da nicht sagen kann, wie es nun letztendlich in Linux realisiert wurde) ....

EDIT:

Habe grade mal geschaut, es gibt zwar settings für MsgQueues, SharedMem und Semaphores, aber habe leider nichts speziell für unix domain sockets gefunden ...

EDIT2:

 *Quote:*   

> source s_local { unix-stream("/dev/log" max_connections(1000)); };
> 
> The number of required connections greatly depend on your local
> 
> configuration. Basically each logging process need one connection to
> ...

 

Du kannst also die Anzahl der erlaubtenverbindungen umsetzen, 100 ist nur der default ....

EDIT3:

Habe das bei syslog-ng noch nicht probiert, aber du könntest mal im normalen betrieb schauen, was ein fuserv -uv /dev/log sagt, bei metalog werden nur die beiden metalog prozesse angezeigt (eigenartig) .... frage mich, was da bei syslog-ng ausgespuckt wird ....

----------

## sambatasse

Also irgendwie scheint das Problem schwerer zu wiegen.

Jetzt hatt sich schon zum 3 mal der Server verabschiedet.

Wie zuvor geht nur ping.

Die logs in der entsprechenden Zeit sind leer.

Ick hoffe mir kann jemand helfen derweillen gehe ick mal rebooten.

----------

## sambatasse

hir Log des Ausfalls 

nix mehr bis zum Reboot

 *Quote:*   

> Jan 29 04:20:03 x /usr/sbin/cron[19801]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
> 
> Jan 29 04:30:04 x /usr/sbin/cron[19879]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
> 
> Jan 29 04:40:03 x /usr/sbin/cron[20019]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
> ...

 

dann boot er normal nix auffälliges bis auf sowas

ich denke das liegt an dem reset

 *Quote:*   

> 
> 
> Jan 29 09:25:57 x ext3_orphan_cleanup: deleting unreferenced inode 877831
> 
> Jan 29 09:25:57 x ext3_orphan_cleanup: deleting unreferenced inode 65508
> ...

 

etwas in den Logs das mir garnix sagt

 *Quote:*   

> 
> 
> Jan 30 19:37:19 x Unable to handle kernel NULL pointer dereference at virtual address 00000018
> 
> Jan 30 19:37:19 x printing eip:
> ...

 

ansonsten nur km weise

 *Quote:*   

> 
> 
> Jan 30 11:55:09 x sshd[14453]: error: Could not get shadow information for NOUSER
> 
> Jan 30 11:55:09 x sshd[14453]: Failed password for illegal user adele from 81.3.182.42 port 60870 ssh2

 

oder

 *Quote:*   

> Feb  1 03:58:58 x sshd[1752]: Failed password for root from 194.146.224.135 port 34878 ssh2
> 
> Feb  1 03:58:59 x sshd[1754]: Failed password for root from 194.146.2
> 
> 

 

oder

 *Quote:*   

> 
> 
> Jan 31 19:20:20 x imapd: LOGIN FAILED, ip=[217.93.58.114]
> 
> Jan 31 19:20:20 x imapd: DISCONNECTED, ip=[217.93.58.114], time=5
> ...

 

----------

## kurt

hi

vileicht ist es auch nur was simples

schau doch bitte mal die /etc/crontab an

falsch

```
*  *  * * *  root    test -x /usr/sbin/run-crons && /usr/sbin/run-crons
```

richtig

```
*/10  *  * * *  root    test -x /usr/sbin/run-crons && /usr/sbin/run-crons
```

oder ob sonst ein cron auf "* * * * *" steht.

das kann solche efeckte auslössen wie du sie erlebst.

gruss

kurt

----------

## DarKRaveR

 *sambatasse wrote:*   

> hir Log des Ausfalls 
> 
> nix mehr bis zum Reboot
> 
>  *Quote:*   Jan 29 04:20:03 x /usr/sbin/cron[19801]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
> ...

 

Sieht okay aus, hier an Kurt: Augen auf, da sieht man schön, daß die cronjobs alle 10 minuten in der crontab gespawned werden, es sei denn er hätte sonst die crontab vergewaltigt ....

 *Quote:*   

> 
> 
> dann boot er normal nix auffälliges bis auf sowas
> 
> ich denke das liegt an dem reset
> ...

 

Sieht nach nem typischen gecrashten FS aus, bin allerdings kein ext3 user, aber das wegwerfen, von inodes, die als unbeledt ercheinen drüfte durchaus aus nem reset resultieren ..

 *Quote:*   

> 
> 
> etwas in den Logs das mir garnix sagt
> 
>  *Quote:*   
> ...

 

Da würde ich mal meinen, daß es den KErnel so richtig schön geklatscht hat, auch Linuxkernel sind weit von Fehlerfreiheit entfernt, kann aber natürlich auch durch hardware ausgelöst werden ...

----------

## moe

Und das

 *Quote:*   

> Jan 30 11:55:09 x sshd[14453]: error: Could not get shadow information for NOUSER
> 
> Jan 30 11:55:09 x sshd[14453]: Failed password for illegal user adele from 81.3.182.42 port 60870 ssh2
> 
> Feb 1 03:58:58 x sshd[1752]: Failed password for root from 194.146.224.135 port 34878 ssh2
> ...

 

sind Versuche eines ssh-Bots mit Standard user/pass-Kombinationen in dein System einzudringen.. Zur Zeit normal, aber trotzdem solltest du mal mit lastlog prüfen obs wirklich nicht geklappt hat, und das System auf andere Auffälligkeiten untersuchen..

Gruss Maurice

----------

