Centos 6 login problemen

[Mr_Big]

Ik draai een aantal VMs op Virtualbox 4.0.10 en dat gaat altijd zonder problemen. Laatst heb ik een tweetal Centos 6 VMs opgezet om daar eens mee te testen, maar die geven een vreemd probleem waar ik niet echt de vinger op kan leggen: eens in de zoveel tijd lukt het niet om in te loggen op de VMs. Bij de ene gebeurt dat vaker dan bij de andere, maar ik kan geen oorzaak aanwijzen.
De applicaties die op de server draaien kan ik wel gewoon gebruiken.

Inloggen met zowel SSH + certificaat als direct met user/ww op de console geeft beide problemen. Alleen door een herstart kom ik er weer in.

Om wat meer info te achterhalen, heb ik de verbose info aangezet tijdens een SSH-sessie naar de server als die problemen geeft:

code:

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.123.52 [192.168.123.52] port 22.
debug1: Connection established.
debug1: identity file /home/rsnapshot/.ssh/identity type -1
debug1: identity file /home/rsnapshot/.ssh/id_rsa type 1
debug1: identity file /home/rsnapshot/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.123.52' is known and matches the RSA host key.
debug1: Found key in /home/rsnapshot/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied


debug1: Next authentication method: publickey
debug1: Trying private key: /home/rsnapshot/.ssh/identity
debug1: Offering public key: /home/rsnapshot/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting [e-mail]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8

Hier blijft hij hangen. Als ik dan op enter druk, krijg ik wel te zien wanneer mijn laatste inlog is geweest ("Last login: Sun Aug 7 08:44:24 2011 from 192.168.123.51"), maar kan ik niks doen:

Iemand een idee?

[Hero of Time]

Het kan liggen aan VB. Update het naar 4.0.12 en zie hoe dat gaat. Als je op de console kan aanmelden zonder problemen, ongeacht hoe lang de VM al draait, dan is het een netwerk probleem. Hoe is je het netwerk ingesteld voor de VM? Bridged, NAT of Host-Only?

Ik zie nu ook dat het met de console het geval is. In zo'n geval zou ik htop installeren (die vind ik net even wat overzichtelijker dan gewoon top) en laat deze draaien in een TTY waarna je verscheidene keren probeert om aan te melden op de console of via SSH. Kijk naar de resources die gebruikt worden, voor hetzelfde geld is er een proces die uit z'n plaat gaat.

[Mr_Big]

Netwerk is ingesteld als bridged met static dhcp via de router.
Heb even een paar keer ingelogd, maar zie geen resource 'spikes' o.i.d. Eigenlijk gebeurt er zo goed als niets bij het inloggen. Lijkt er dus niet op dat er processen verkeerd zitten.

Ik ga VB 4.0.12 eigenlijk pas installeren bij de volgende Windows update, dan kan alles tenminste in één keer worden herstart. Maar kan me niet voorstellen dat het daar aan ligt, aangezien de Centos 5 VMs al jaren prima draaien.

[Hero of Time]

Ok, er is dus niets op zowel je Guest als Host die mogelijke traagheid kan veroorzaken? Heb je op het CentOS forum al gekeken of dit bekend is bij ze? Heb je de Guest Additions geïnstalleerd toevallig, en zoja, is dit van VB zelf, of die uit de CentOS repo? Ze kunnen conflicten geven en verouderde Additions kan problemen geven. Dit merk je dan pas later.
Kunnen we er ook vanuit gaan dat als je eenmaal bent aangemeld, er geen probleem is met je sessie en dat het pas optreed als je een nieuwe sessie wilt starten?

[Mr_Big]

Er draaien meerdere guests op de host: iets van 4 Cento 5 en 2 Centos 6. Als één van de Centos 6 guests het eerder beschreven probleem heeft, draaien de anderen gewoon door. Ook de applicaties op de guest met problemen doen het gewoon: alleen inloggen op de console lukt niet. Ik heb nog nooit gehad dat er een sessie werd verbroken, waarna ik niet meer kon inloggen.

Guest additions zijn geinstalleerd en afkomstig van VB. Die worden bij installatie netjes gecompileerd voor de geinstalleerde kernel.

Helaas heb ik elders niets gevonden, daarom kom ik ook hier als laatste redmiddel ;-)

Ik had ook al gedacht te upgraden naar 4.1.0, maar die geeft weer problemen met snapshots. Zo is het altijd weer wat...

[ Voor 9% gewijzigd door Mr_Big op 08-08-2011 21:13 ]

[Hero of Time]

Ik draai zelf 4.1.0 (moet eigenlijk ook wel, ben moderator op het forum) maar heb geen enkel probleem met snapshots. Maar ik raad je voor nu af om 4.1.0 te gebruiken totdat het verder ontwikkeld is (v.a. 4.1.4 bijvoorbeeld is een betere tijd).

Het is dus alleen met je CentOS 6 VM en de rest geeft geen problemen. Het is dus ook alleen als je een nieuwe sessie wilt starten, alle bestaande sessies geven geen problemen.

Guest additions zijn geinstalleerd en afkomstig van VB. Die worden bij installatie netjes gecompileerd voor de geinstalleerde kernel.

Dit staat wat vreemd imo. Ze zijn afkomstig van VB, ok, dus dan heb je dat met de ISO gedaan door 'm te laden als CD en de installer te runnen. Maar de tweede zin lees ik op zo'n manier dat lijkt alsof het bij de standaard installatie van CentOS is gedaan. Dat betekend dan weer dat ze uit de repo komen.

Ik ben verder geen CentOS expert en heb momenteel niet de resources (lees: schijfruimte) om een aparte VM ermee te installeren om te kijken of ik het probleem ook krijg. Hopelijk dat iemand anders met CentOS ervaring hier meer over kan zeggen.

Laatste wat ik nog wel wil weten is of je in de logs iets vind. Dmesg, syslog, messages, er zal vast wel ergens iets staan waar dit door komt.

[Mr_Big]

Gisteren de Windows updates geïnstalleerd en gelijk ook 4.0.12. Eens kijken of dat het probleem verhelpt.
Afgemeten aan het aantal reacties: vreemd trouwens dat niemand anders dit probleem lijkt te hebben

[Hero of Time]

Ja, idd. Ik had ook verwacht dat een andere Tweaker dit probleem kent of eventueel verder kan helpen. Hopelijk is 't opgelost met je 4.0.12. Vergeet niet de GA te updaten .

[Mr_Big]

Vandaag toch weer het probleem.
Één van de SugarCRM instances wilde ook niet meer reageren, de andere instances wel.
Helaas is er eigenlijk niks te zien in de logfiles, dus ben nog geen stap verder.

[Hero of Time]

En de logs van de VM zelf? Rechtsklik op de VM naam > Show log.

[Mr_Big]

de logs zijn een beetje moeilijk te lezen, omdat de tijd wordt weegegeven vanaf het opstarten (denk ik) i.p.v. de normale kloktijd.
Ik vermoed echter dat het volgende het probleem is:

Changing the state from 'RUNNING' to 'SUSPENDING'.

Enkele minuten later gebeurt dan het omgekeerde. De volgende actie is dat ik de VM een 'harde' reset geef en dat hij opnieuw opstart.
Ik denk dus dat ik het moet zoeken in de power settings van Centos 6 o.i.d.
Ik zal sowieso eens in de gaten houden of dit alleen in het weekend gebeurt, wanneer ik de applicaties op die server dus een tijd niet gebruik. Zoals je kan zien was mijn 1e post vorige week zondag, dus dat is wel erg verdacht. Kan dus ook iets in cron zijn...

[Hero of Time]

Je power settings controleren is zeker een goed idee. Als je een GUI hebt, kan een power manager draaien die dan de boel op standby zet oid na x minuten idle. Zeer vervelend als je met SSH werkt, al zou het wel moeten stoppen als je een SSH sessie hebt. Maar als een deel gecached wordt, kan dat nou net het begin van de sessie zijn, waarna je dus niets meer kan omdat de cache daar ophoud en de VM eigenlijk suspended is.
Houd 't in de gaten en laat 't weten.

[Mr_Big]

Ik kan nergens iets over power management vinden. Jij ideeën?
Gaat om een standaard serverinstallatie, zonder GUI.

[CAPSLOCK2000]

Als je niet kan inloggen op de console, wat gebeurt er dan precies?
Krijg je wel een "login:" prompt te zien of niet?

Ik vraag het omdat ik net zelf een inlog-probleem had met een RHEL5 machine.
Op de (virtuele) console krijg ik wel een login: prompt, maar die wordt niet gevolgd door een password: prompt . Zodra ik op enter druk krijg ik een "Login incorrect". Na een paar keer proberen mag ik er wel in.

Mijn /var/log/auth.log bevat klachten over "Deprecated pam_stack module called from service "login"" .

Op dit systeem wordt de PAM configuratie flink aangepast, ik denk dat het daar mee te maken heeft. Vergelijkbare problemen had ik ooit toen ik een 64bit pam-module probeerde te gebruiken op een 32-bit systeem (of andersom).

[ Voor 0% gewijzigd door CAPSLOCK2000 op 17-08-2011 11:55 . Reden: spelling & grammatica ]

[Mr_Big]

Als ik direct op de console (dus via scherm VB0 inlog krijg ik wel de login prompt te zien en kan ik ook mijn wachtwoord invoeren. Daarna kan ik wachten wat ik wil: er gebeurt verder niets.
Het gekke is dat als ik dan op enter druk, ik wel een gewone prompt te zien krijg, maar daar kan ik verder niks.

Via SSH log ik in met een certificaat. Daar wordt volgens mij ook ingelogd, maar krijg ik de prompt nooit te zien.

[Remco]

En als je na het inloggen CTR+C doet ?
Misschien draait er een loginscript wat blijft hangen ?

[Mr_Big]

Als het weer gebeurt zal ik dat eens proberen.
Heb nu wel geupgraded naar 4.1.2, dus mogelijk heeft dat de problemen al opgelost.