Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Plantage I/O error

ymai

Bonjour
Soit une machine FC5 serveur Samba PDC sur un domaine Windows. Le serveur s'appelle "didactique" pour Linux et "Serveur_didac" pour Samba. Il tourne en production depuis un mois.
Aujourd'hui, par deux fois, j'ai un plantage complet du domaine: plus d'accès au serveur pour les machines Windows, domaine inaccessible lors des tentatives de login.
La première fois, j'ai redémarré le serveur pour pallier le problème au plus vite.

Dans l'intervalle, je me suis connecté par une session Putty depuis une machine Windows sur ledit serveur. On me prévient d'une nouvelle interruption du service. Dans ma console Putty, j'ai effectivement:

Message from syslogd@didactique at Mon Oct 2 16:01:08 200
didactique kernel: journal commit I/O error

D'après ce que je pense avoir compris, il s'agit sans doute d'un problème hardware, probablement au niveau du disque dur de mon serveur.
Quelqu'un pourrait-il m'aiguiller sur:
- les recherches à faire pour avoir plus d'informations sur la nature de l'incident; y a-t-il un log dans lequel il peut être répertorié?
- quels tests faire pour vérifier l'état du disque dur?

Quelques autres indices.
Lors du premier plantage, un utilisateur Windows venait de subir un plantage de son Ooo 2.0.2. L'incident semble s'être produit en même temps que la tentative de restauration des documents en cours d'édition. Coïncidence?
Il me semble que c'est lors du deuxième plantage, qu'un autre utilisateur a retrouvé ses documents en lecture seule, au retour du serveur. Dans Windows, aucune raison de penser que les fichiers étaient Ro. Etrange.
Je devrai vérifier l'état actuel de ces fichiers demain.

Je ne suis pas 100% formel sur la chronologie des événements. Mais deux plantages successifs à quelques minutes d'intervalle ne vont pas sans m'inquiéter.
D'autant que je pense avoir eu le même souci il y a une semaine. Redémarrage en force (bouton On/off) du serveur FC5 qui ne répondait plus du tout au clavier.

Merci pour toute aide, pas trop technique, svp: mes connaissances Linux sont basiques.

Anvil

- les recherches à faire pour avoir plus d'informations sur la nature de l'incident; y a-t-il un log dans lequel il peut être répertorié?
- quels tests faire pour vérifier l'état du disque dur?

Vois les fichiers /var/log/messages*. Chaque ligne est taggee avec la date. Y'a de bonne chances que ce soit suffisant pour dire si oui ou non un disque est mort ou partiellement corrompu... et donc pas besoin de "tests". Tu peux toujours jouer avec `fsck -c' (man fsck, man fsck.ext3) si tu y tiens vraiment, mais ca risque d'entrainer de nombreuses heures d'indisponibilite auxquelles tu n'as pas l'air de tenir tant que ca.

ymai

Merci pour ces informations.
Les heures d'indisponibilités pourraient prendre place durant un week-end.
Disons que là, j'avais 16 élèves qui devaient travailler et un prof qui me talonnait parce qu'il n'avait plus accès à ses documents.
Je regarde tout ça et... je reviens avec mes nouvelles questions :o)

Anvil

Hesite pas a nous coller tes messages en cas de besoin. Aussi, suivant les cas, il est possible que le disque ne soit pas *reellement* en cause. Par exemple, un probleme de ram aurait pu corrompre le noyau et le filesystem pour mener a un kernel panic. Il faut savoir quelle couche du noyau parle quand on lit var/log/messages ou dmesg.

eddy33

hum...

Oui, regarde aussi du cote du DD mais aussi de la RAM.
Infos DD par SMART :
# smartctl -a /dev/hda

Tests de la RAM. Boot sur le CD 1 d'install ou le DVD et :
boot: memtest86

++

ymai

Bonjour
Fort de vos idées, je m'en viens donc ausculter mon serveur.
A priori, pas grand chose d'intéressant dans /var/log/messages
Quelques minutes avant le premier plantage, il me semble noter une activité "normale". A 15h37, s'est connecté sur la station prof01. Ce que me confirment les logs de Samba.
Le même utilisateur s'est d'ailleurs reconnecté à 16h53 sans que cela provoque de catastrophe.
Par contre, pas de trace du plantage: seulement le retour en service à 15h54.

Oct 2 15:35:27 didactique kernel: audit(1159796127.456:1122): avc: denied { rename } for pid=15024 comm="smbd" name="DACT.TTX" dev=sda3 ino=8520693 scontext=root:system_r:smbd_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file
Oct 2 15:37:41 didactique smbd[15124]: [2006/10/02 15:37:41, 0] smbd/service.c:make_connection(846)
Oct 2 15:37:41 didactique smbd[15124]: prof01 (172.16.95.52) couldn't find service profil
Oct 2 15:37:41 didactique smbd[15124]: [2006/10/02 15:37:41, 0] smbd/service.c:make_connection(846)
Oct 2 15:37:41 didactique smbd[15124]: prof01 (172.16.95.52) couldn't find service profil
Oct 2 15:54:57 didactique syslogd 1.4.1: restart.
Oct 2 15:54:57 didactique kernel: klogd 1.4.1, log source = /proc/kmsg started.
Oct 2 15:54:57 didactique kernel: Linux version 2.6.15-1.2054_FC5smp (bhcompile@hs20-bc1-3.build.redhat.com) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #1 SMP Tue Mar 14 16:05:46 EST 2006
......

Y aurait-il des informations plus précises dans le même fichier aux alentours de l'heure du deuxième plantage?

Oct 2 16:00:54 didactique kernel: audit(1159797654.787:80): avc: denied { lock } for pid=2425 comm="smbd" name=5468756E6465726269726420536574757020312E352E302E352E657865 dev=sda3 ino=40404174 scontext=system_u:system_r:smbd_t:s0 tcontext=root:object_r:user_home_dir_t:s0 tclass=file
Oct 2 16:00:55 didactique kernel: audit(1159797655.259:81): avc: denied { read } for pid=2425 comm="smbd" name="ff.exe" dev=sda3 ino=40404120 scontext=system_u:system_r:smbd_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=file
Oct 2 16:00:55 didactique kernel: audit(1159797655.259:82): avc: denied { lock } for pid=2425 comm="smbd" name="ff.exe" dev=sda3 ino=40404120 scontext=system_u:system_r:smbd_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=file
Oct 2 16:00:55 didactique kernel: audit(1159797655.263:83): avc: denied { setattr } for pid=2425 comm="smbd" name="ff.exe" dev=sda3 ino=40404120 scontext=system_u:system_r:smbd_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=file
Oct 2 16:00:55 didactique kernel: audit(1159797655.263:84): avc: denied { fowner } for pid=2425 comm="smbd" capability=3
scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:system_r:smbd_t:s0 tclass=capability
Oct 2 16:04:35 didactique syslogd 1.4.1: restart.
Oct 2 16:04:35 didactique kernel: klogd 1.4.1, log source = /proc/kmsg started.
Oct 2 16:04:35 didactique kernel: Linux version 2.6.15-1.2054_FC5smp (bhcompile@hs20-bc1-3.build.redhat.com) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #1 SMP Tue Mar 14 16:05:46 EST 2006
.....

Je vais faire le test de RAM sur une autre machine dont j'échangerai la mémoire.
Quant au test du DD, j'ai l'impression que la commande suggérée par eddy33 ne peut fonctionner sur un disque Sata.

[root@didactique mai]# /usr/sbin/smartctl -a /dev/sda
smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: ATA Maxtor 6V200E0 Version: VA11

SATA disks accessed via libata are not currently supported by
smartmontools. When libata is given an ATA pass-thru ioctl() then an
additional '-d libata' device type will be added to smartmontools.
[root@didactique mai]#

Merci encore pour les idées.

ymai

Dégâts collatéraux...
En tentant de gérer mes utilisateurs à l'aide de
> Bureau > Administration > Utilisateurs et groupes, je reçois l'avertissement:
"Impossible de lire la base de données de l'utilisateur (sic).
Il semble que /etc/passwd et /etc/shadow ne soient pas synchronisés. Le programme va maintenant quitter."

C'est grave docteur? Y a-t-il une méthode simple et sans danger pour re-synchroniser?

eddy33

hum...
pour tes utilisateurs, en mode non graphique, est-ce que ca marche, c a d est-ce qu'ils peuvent se connecter sur leur compte dans ce mode ?
pour le smartool, je regarderai ce soir : je suis au boulot...

++

ymai

Bonjour
Mes utilisateurs sont tous clients Windows. Ils se connectent parfaitement à leur compte Samba; ce qui est évidemment tout autre chose. Mais ils sont parfaitement reconnus.
J'ai même pu ajouter un utilisateur sans problème et en changer un autre de groupe (enfin, la commande usermod a accepté sans rechigner). Je me loggue également sans problème sur ce serveur avec mon compte (non root).

grosminet

tu ne trouvera rien d'interessant sur I/O car le problème pourrait provenir que kjournal n'arrive pas à acceder au disque dur.
le problème d'accès dma sur le disque.
si tu va voir la console sur le serveur, tu aura une partie de reponse
la frequence du probleme va s'accelerer voir s'amplifier.
conseil: sauvegarde generale et replacer le disque dur
j'ai une machine qui a ce symptome.
j'ai installé le disque dur sur plusieurs machines
meme symptome
j'ai recharge linux et au bout d'un certain temps meme symptome
Mais il semble bizarre la deuxieme erreur qui pourra expliquer le phenomene et lueur d'espoir
comment geres tu les accès multiples de fichiers samba partagés ?
voir ton smb.conf
on dirait un probleme d'acces sur le serveur samba de fichiers verrouillés

ymai

Merci grosminet. Voilà qui n'est guère rassurant. Je m'en vais donc préparer cette sauvegarde. Le cas échéant, je reviendrai dans un autre fil, à ce sujet. J'ai dans l'idée qu'un Norton Ghost, depuis le CD bootable, ne fonctionnera pas sur les partitions Linux...

"Voir la console sur le serveur." Est-ce à dire que je dois laisser une console ouverte en permanence et garder un oeil sur les messages qui y apparaîtraient? Désolé pour la question idiote, mais mes connaissances sont très limitées.

"La deuxième erreur"? J'en ai rapporté tellement que je ne sais plus trop à quoi cela peut faire référence.
Serait-ce le blocage en lecture seule? Il concernait un partage personnel accessible à un seul utilisateur. Hors de cause, donc, dans cette hypothèse.

A ce jour, j'ai ouvert un seul partage qui permette des accès concurrents. Mais les utilisateurs "élèves" n'y ont pas accès.
Je n'ai pas le smb.conf sous la main là, maintenant, tout de suite. Demain.

Autre hypothèse: j'ai fait quelque chose d'un peu particulier qui permet de fixer un profil Windows identique à tous mes utilisateurs "élèves". Dans un "root preexec", un profil type est recopié dans le /home de chaque utilisateur au moment de la connexion. Solution bricolée "maison" car il semble que personne n'ait jamais eu besoin de faire cela. Etonnant, non?
Il y a donc, effectivement accès simultané au répertoire contenant le profil "type".
Mais, si le problème était là, ne devrait-on pas constater des soucis au moment où mes utilisateurs se connectent simultanément, c'est-à-dire au début du cours. A l'heure des plantages, personne ne faisait usage du profil type; la personne qui se logguait était un "prof", avec un profil libre.

Puis-je revenir ce mercredi avec mon smb.conf ?
Merci pour tout le remue-méninges.

grosminet

En regardant de plus pres par rapport a tes dires
Oct 2 15:35:27 didactique kernel: audit(1159796127.456:1122): avc: denied { rename } for pid=15024 comm="smbd" name="DACT.TTX" dev=sda3 ino=8520693 scontext=root:system_r:smbd_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file
Oct 2 15:37:41 didactique smbd[15124]: [2006/10/02 15:37:41, 0] smbd/service.c:make_connection(846)
Oct 2 15:37:41 didactique smbd[15124]: prof01 (172.16.95.52) couldn't find service profil
Oct 2 15:37:41 didactique smbd[15124]: [2006/10/02 15:37:41, 0] smbd/service.c:make_connection(846)
Oct 2 15:37:41 didactique smbd[15124]: prof01 (172.16.95.52) couldn't find service profil
Oct 2 15:54:57 didactique syslogd 1.4.1: restart.
Oct 2 15:37:41 didactique smbd[15124]: prof01 (172.16.95.52) couldn't find service profil
met selinux en permissive et protege ton demon samba
on ne sait jamais
pour la console tu peux ouvrir une session root en tty et lancer vlock pour la securite
quelle est ta partition
df -h
l'erreur est elle toujours present ?
"Impossible de lire la base de données de l'utilisateur (sic).
Il semble que /etc/passwd et /etc/shadow ne soient pas synchronisés. Le programme va maintenant quitter."

ymai

Voici déjà le smb.conf . Merci à ceux qui auront le courage de l'examiner à la recherche d'une faille.

[global]
workgroup = didactique
netbios name = serveur_didac
server string = Serveur Didactique %L
security = user
encrypt passwords = yes
domain master = yes
local master = yes
preferred master = yes
os level = 66
domain logons = yes
time server=yes
logon path = \%Lprofile
logon drive = P:
log file = /var/log/samba/%m.log
logon script = logon.bat %g
add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null -g MachineSamba %u
[netlogon]
path = /home/netlogon
writeable = no
browseable = no
guest OK = no
[profile]
path = /home/%g/%u/profile
writeable = yes
browseable = no
root preexec = php /opt/profil.php %g %u
[homes]
path = /home/%g/%u
writeable = yes
browseable = no
guest OK = no
create mask = 0770
directory mask = 0750
[eleves]
path = /home
writeable = yes
browseable = yes
guest OK = yes
[tdt]
path = /home/eleves/Tdt
writeable = no
browseable = yes
guest OK = yes
[installe]
path = /home/installe
writeable = yes
browseable = yes
guest ok = yes
[profs]
path = /home/profs
writeable = yes
browseable = no
guest OK = no
valid users = @profs
[communprofs]
path = /home/profs/commun
writeable = yes
browseable = yes
guest OK = no
create mask = 0770
directory mask = 0770
valid users = @profs

Le root preexec de la section [profile] fait référence à profil.php que voici:
<?php
$groupe=$_SERVER["argv"][1];
$user=$_SERVER["argv"][2];
if($groupe!='profs'){
system("rm -rf /home/$groupe/$user/profile");
system("cp -rf /opt/profiles /home/$groupe/$user/profile");
system("chown -R $user:profs /home/$groupe/$user/profile");
}
?>
S'il s'agit d'un utilisateur du groupe "profs", on ne fait rien. Sinon, on recopie le profil type depuis /opt/profiles
Ici, il pourrait y avoir des accès concurrents lorsque plusieurs utilisateurs se connectent en même temps. Mais, jusqu'à maintenant, aucun souci constaté à ce moment précis.

ymai

grosminet a écrit :
met selinux en permissive

Il y était déjà.

et protege ton demon samba

Dans la boîte de dialogue > onglet SeLinux, je ne pourrais que cocher la case "Désactiver la protection SeLinux pour le démon smbd".
Est-ce donc à dire qu'il est déjà protégé?

pour la console tu peux ouvrir une session root en tty et lancer vlock pour la securite

quelle est ta partition
df -h

Ceci est-il la réponse à la question? :o(
[mai@didactique ~]$ df -h
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/sda2 15G 2,5G 12G 19% /
/dev/sda1 99M 9,8M 84M 11% /boot
tmpfs 501M 0 501M 0% /dev/shm
/dev/sda3 168G 6,8G 153G 5% /home

l'erreur est elle toujours present ?
"Impossible de lire la base de données de l'utilisateur (sic).
Il semble que /etc/passwd et /etc/shadow ne soient pas synchronisés. Le programme va maintenant quitter."

Plus que jamais... Mais le système fonctionne toujours...

Je sais (dans d'autres domaines) à quel point un newbie peut être exaspérant. Merci pour votre patience.

Anvil

c'est pas selinux qui va faire faire des I/O error au journal ext3. Je suggere de laisser tomber cette piste de toute evidence inutile.

ymai

Je prends bonne note, mais cela revient donc à tout laisser en l'état initial.

Dans la console, j'ai vu passer quelques avertissements "denied" concernant l'accès au fichier NTUSER.DAT du profil Windows. J'ai donc encore quelques soucis à régler de ce côté-là aussi, sans doute. Bien que les utilisateurs Win sous Samba roulent parfaitement.
Y a-t-il un endroit où je puis retrouver ces messages passés un peu trop fugacement?

Bientôt, je change de pseudo. Je prends "le boulet".

grosminet

awk ' { print NR $1 } ' < shadow
awk ' { print NR $1} ' < passwd
comparer les sorties sur le nombre
il ya des fortes chances d'une divergence
par contre pour gerer les confits d'accès au ressources
Windows defines 4 kinds of Oplocks:
Level1 Oplock ? The redirector sees that the file was opened with deny none (allowing
concurrent access), verifies that no other process is accessing the file, checks that
oplocks are enabled, then grants deny-all/read-write/exclusive access to the file. The
client now performs operations on the cached local file.
If a second process attempts to open the file, the open is deferred while the redirector
?breaks? the original oplock. The oplock break signals the caching client to write the
local file back to the server, flush the local locks and discard read-ahead data. The
break is then complete, the deferred open is granted, and the multiple processes can
enjoy concurrent file access as dictated by mandatory or byte-range locking options.
However, if the original opening process opened the file with a share mode other than
deny-none, then the second process is granted limited or no access, despite the oplock
break.
Level2 Oplock ? Performs like a Level1 oplock, except caching is only operative for
reads. All other operations are performed on the server disk copy of the file.
Filter Oplock ? Does not allow write or delete file access.
Batch Oplock ? Manipulates file openings and closings and allows caching of file attributes.

You can disable oplocks on a per-share basis with the following:
oplocks = False
level2 oplocks = False
The default oplock type is Level1. Level2 oplocks are enabled on a per-share basis in the
smb.conf file.
Alternately, you could disable oplocks on a per-file basis within the share:
veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/
If you are experiencing problems with oplocks as apparent from Samba?s log entries, you
may want to play it safe and disable oplocks and Level2 oplocks.
13.3.1.2 Disabling Kernel Oplocks
Kernel oplocks is an smb.conf parameter that notifies Samba (if the UNIX kernel has the
capability to send a Windows client an oplock break) when a UNIX process is attempting
to open the file that is cached. This parameter addresses sharing files between UNIX and
Windows with oplocks enabled on the Samba server: the UNIX process can open the file
that is Oplocked (cached) by the Windows client and the smbd process will not send an
oplock break, which exposes the file to the risk of data corruption. If the UNIX kernel has
the ability to send an oplock break, then the kernel oplocks parameter enables Samba to
send the oplock break. Kernel oplocks are enabled on a per-server basis in the smb.conf
file.
kernel oplocks = yes
The default is no.
Veto opLocks is an smb.conf parameter that identifies specific files for which oplocks are
disabled. When a Windows client opens a file that has been configured for veto oplocks, the
client will not be granted the oplock, and all operations will be executed on the original file
on disk instead of a client-cached file copy. By explicitly identifying files that are shared with
UNIX processes and disabling oplocks for those files, the server-wide Oplock configuration
Section 13.4. MS Windows Opportunistic Locking and Caching Controls 185
can be enabled to allow Windows clients to utilize the performance benefit of file caching
without the risk of data corruption. Veto Oplocks can be enabled on a per-share basis, or
globally for the entire server, in the smb.conf file as shown in Example 13.1.
Example 13.1. Share with some files oplocked
[global]
veto oplock files = /filename.htm/*.txt/
[share name]
veto oplock files = /*.exe/filename.ext/
oplock break wait time is an smb.conf parameter that adjusts the time interval for
Samba to reply to an oplock break request. Samba recommends: ?Do not change this
parameter unless you have read and understood the Samba oplock code.? Oplock break Wait
Time can only be configured globally in the smb.conf file as shown below.
oplock break wait time = 0 (default)
Oplock break contention limit is an smb.conf parameter that limits the response of the
Samba server to grant an oplock if the configured number of contending clients reaches the
limit specified by the parameter. Samba recommends ?Do not change this parameter unless
you have read and understood the Samba oplock code.? Oplock break Contention Limit can
be enable on a per-share basis, or globally for the entire server, in the smb.conf file as
shown in Example 13.2.
Example 13.2. Configuration with oplock break contention limit
[global]
oplock break contention limit = 2 (default)
[share name]
oplock break contention limit = 2 (default)

ymai

grosminet a écrit :
awk ' { print NR $1 } ' < shadow
awk ' { print NR $1} ' < passwd
comparer les sorties sur le nombre
il ya des fortes chances d'une divergence

En gros, cela me permettra de confirmer qu'il y a un souci?
Il me semble avoir vu qu'il existe une commande pour régénérer le fichier shadow, à partir du fichier passwd. Je ne retrouve pas les infos ici. Y a-t-il un problème à tenter cela?
J'ai cru voir des choses bizarres, quand j'ai regardé le fichier shadow, tout à l'heure. J'aurais dû faire un copier/coller. Mais j'était trop pressé, ayant 10 casseroles sur le feu en même temps. Est-il même possible que j'y aie vu des mots de passe en clair???

par contre pour gerer les confits d'accès au ressources
Windows defines 4 kinds of Oplocks:

J'approfondis cette affaire d'Oplocks au plus vite. Cette doc a déjà l'air bien détaillée. J'avoue que c'est un point que j'avais allègrement sauté dans la littérature relative à Samba.

Ce w.e., je vais sans doute pouvoir faire les tests sur la mémoire et sur le HD.
Merci pour toutes les infos.

grosminet

1) determiner la divergence entre les deux fichiers au niveau des utilisateurs
il se peut qu'un utilisateur soit inscrit dans etc/password et non dans etc/shadow
il faut le supprimer en ligne de commande par defaut
peut reinitialiser le password sous root
si cela le marche pas, jamais executé mais il faudra le supprimer par vi -b ( peut etre en binaire par securité
peut creer le password sous root
controle tes fichiers smbpasswd et smbusers
tous les utilisateurs doivent etre declarés en tant qu'utilisateur sous linux

ymai

grosminet a écrit :
1) determiner la divergence entre les deux fichiers au niveau des utilisateurs
il se peut qu'un utilisateur soit inscrit dans etc/password et non dans etc/shadow

ou que /etc/shadow soit un tantinet perturbé. D'où mon idée, peut-être saugrenue, de le régénérer.

il faut le supprimer en ligne de commande par defaut

userdel, donc?

peut reinitialiser le password sous root

Heuuuu?????

si cela le marche pas, jamais executé mais il faudra le supprimer par vi -b ( peut etre en binaire par securité
peut creer le password sous root

Y aurait-il une hypothèse sur la cause qui aurait pu provoquer une telle catastrophe dans /etc/shadow? Un raté sur le DD au moment où un utilisateur s'est connecté?
Sans même être ouvert en écriture, le fichier aurait pu se corrompre?

controle tes fichiers smbpasswd et smbusers

Avec plus de 1100 utilisateurs, ça risque de me prendre un peu de temps ;o))

Et j'ai encore plein de questions en réserve ;o))

Page suivante »