Plantage serveur

par **trixel** » 13 Sep 2007 09:36

Bonjour tout le monde.

Voilà j'ai un souci sur un serveur en production :

lors de la sauvegarde avec rsync sur un lecteur de bande IOMEGA REV, ça semble faire planter le serveur, mais pas tout le temps, je vous copie le log ci-dessous, si qqun a une idée c cool !!
Je sais pas si le problème vient de la bande qui est defectueuse ?? ou du DD ?
sachant que rsync me renvoie souvent des erreurs sur certains fichiers qui n'ont pas pu etre copiés.

Code: Tout sélectionner: Sep 12 23:01:15 serveur kernel: udf: udf_read_inode(ino 9037199) failed !bh Sep 12 23:01:15 serveur kernel: udf: udf_read_inode(ino 1079941) failed !bh Sep 12 23:01:15 serveur kernel: udf: udf_read_inode(ino 1079941) failed !bh Sep 12 23:01:16 serveur kernel: udf: udf_read_inode(ino 8451922) failed !bh Sep 12 23:01:16 serveur kernel: Unable to handle kernel paging request at virtual address 1a6e5c4d Sep 12 23:01:16 serveur kernel: printing eip: Sep 12 23:01:16 serveur kernel: f8accda1 Sep 12 23:01:16 serveur kernel: *pde = 00000000 Sep 12 23:01:16 serveur kernel: Oops: 0000 [#1] Sep 12 23:01:16 serveur kernel: SMP Sep 12 23:01:16 serveur kernel: Modules linked in: udf 8139too ipt_ULOG ipt_REJECT ipt_MASQUERADE ipt_state ip_nat_ftp ip_conntrack_ftp iptable_mangle iptable_nat ip_conntrack iptable_filter ip_tables button battery ac ohci_hcd ehci_hcd k8_edac edac_mc mii bonding(U) dm_snapshot dm_zero dm_mirror ext3 jbd raid1 dm_mod sata_nv libata sd_mod scsi_mod Sep 12 23:01:16 serveur kernel: CPU: 0 Sep 12 23:01:16 serveur kernel: EIP: 0060:[<f8accda1>] Not tainted VLI Sep 12 23:01:16 serveur kernel: EFLAGS: 00010246 (2.6.9-55.0.2.ELsmp) Sep 12 23:01:16 serveur kernel: EIP is at udf_get_fileshortad+0x38/0x4b [udf] Sep 12 23:01:16 serveur kernel: eax: 00000000 ebx: 1a6e5c4d ecx: d0885d34 edx: 00000030 Sep 12 23:01:16 serveur kernel: esi: c94d2d5c edi: 1a6e5c4d ebp: d963fe74 esp: d0885c9c Sep 12 23:01:16 serveur kernel: ds: 007b es: 007b ss: 0068 Sep 12 23:01:16 serveur kernel: Process rsync (pid: 10303, threadinfo=d0885000 task=f51808f0) Sep 12 23:01:16 serveur kernel: Stack: d963fe3c d0885d34 f8ac603d 00000001 00000000 00000000 f8000001 c011e80d Sep 12 23:01:16 serveur kernel: 00000000 00000000 c0328b1c 00000001 c0328b14 00000000 00000001 d0885d2c Sep 12 23:01:16 serveur kernel: d963fe74 d0885d44 d0885d34 f8ac5f40 d0885d38 d0885d40 d0885d44 00000001 Sep 12 23:01:16 serveur kernel: Call Trace: Sep 12 23:01:16 serveur kernel: [<f8ac603d>] udf_current_aext+0xee/0x18e [udf] Sep 12 23:01:16 serveur kernel: [__wake_up_common+54/81] __wake_up_common+0x36/0x51 Sep 12 23:01:16 serveur kernel: [<c011e80d>] __wake_up_common+0x36/0x51 Sep 12 23:01:16 serveur kernel: [<f8ac5f40>] udf_next_aext+0x70/0x7f [udf] Sep 12 23:01:16 serveur kernel: [<f8acc083>] udf_discard_prealloc+0x12f/0x23b [udf] Sep 12 23:01:16 serveur kernel: [<f8ac28de>] udf_put_inode+0x36/0x60 [udf] Sep 12 23:01:16 serveur kernel: [iput+48/97] iput+0x30/0x61 Sep 12 23:01:16 serveur kernel: [<c01721d4>] iput+0x30/0x61 Sep 12 23:01:16 serveur kernel: [<f8ac598f>] udf_iget+0xb8/0xc1 [udf] Sep 12 23:01:16 serveur kernel: [<f8ac6ea8>] udf_lookup+0xa6/0x121 [udf] Sep 12 23:01:16 serveur kernel: [d_alloc+373/381] d_alloc+0x175/0x17d Sep 12 23:01:16 serveur kernel: [<c01702c8>] d_alloc+0x175/0x17d Sep 12 23:01:16 serveur kernel: [real_lookup+110/236] real_lookup+0x6e/0xec Sep 12 23:01:16 serveur kernel: [<c016699f>] real_lookup+0x6e/0xec Sep 12 23:01:16 serveur kernel: [do_lookup+93/177] do_lookup+0x5d/0xb1 Sep 12 23:01:16 serveur kernel: [<c0166bdd>] do_lookup+0x5d/0xb1 Sep 12 23:01:16 serveur kernel: [__link_path_walk+2116/3109] __link_path_walk+0x844/0xc25 Sep 12 23:01:16 serveur kernel: [<c0167475>] __link_path_walk+0x844/0xc25 Sep 12 23:01:16 serveur kernel: [link_path_walk+67/190] link_path_walk+0x43/0xbe Sep 12 23:01:16 serveur kernel: [<c0167899>] link_path_walk+0x43/0xbe Sep 12 23:01:16 serveur kernel: [path_lookup+331/383] path_lookup+0x14b/0x17f Sep 12 23:01:16 serveur kernel: [<c0167c2e>] path_lookup+0x14b/0x17f Sep 12 23:01:16 serveur kernel: [__user_walk+33/81] __user_walk+0x21/0x51 Sep 12 23:01:16 serveur kernel: [<c0167d76>] __user_walk+0x21/0x51 Sep 12 23:01:16 serveur kernel: [vfs_lstat64+17/55] vfs_lstat64+0x11/0x37 Sep 12 23:01:16 serveur kernel: [<c0162f32>] vfs_lstat64+0x11/0x37 Sep 12 23:01:16 serveur kernel: [sys_lstat64+15/35] sys_lstat64+0xf/0x23 Sep 12 23:01:16 serveur kernel: [<c016355d>] sys_lstat64+0xf/0x23 Sep 12 23:01:16 serveur kernel: [syscall_call+7/11] syscall_call+0x7/0xb Sep 12 23:01:16 serveur kernel: [<c02d6093>] syscall_call+0x7/0xb Sep 12 23:01:16 serveur kernel: Code: 0f 94 c2 09 d0 a8 01 74 0f 68 52 e7 ac f8 e8 69 5b 65 c7 5a 31 c0 eb 23 8b 01 85 c0 78 07 8d 50 08 39 f2 76 04 31 c0 eb 12 31 c0 <83> 3b 00 74 0b 83 7c 24 0c 00 74 02 89 11 89 d8 5b 5e c3 56 85 Sep 12 23:01:16 serveur kernel: <0>Fatal exception: panic in 5 seconds

par **trixel** » 13 Sep 2007 09:38

petite précision c une SME 7.1.3

et voici le script RSYNC :

Code: Tout sélectionner: mount /dev/hdb mkdir /media/cdrom/ibays mkdir /media/cdrom/users rsync -P -av --exclude='/home/e-smith/files/ibays/sauvegarde/' /home/e-smith/files/ibays/ /media/cdrom/ibays/ rsync -P -av /home/e-smith/files/users/ /media/cdrom/users/

par **jdh** » 13 Sep 2007 09:49

Unable to handle kernel paging request at virtual address 1a6e5c4d

Cela semble un problème de mémoire (pagination). Cela peut être du à une barrette de mémoire physique, à un programme qui se lance et se vautre en chargeant une librairie en mémoire, ....

Ce qui me semble important c'est de regarder si tu peux reproduire à tout coup le phénomène.

Il semble quand même que ce soit bien rsync (et le système de fichier udf) qui se plante. Une latence en lecture du disque ?

J'apprécie assez peu de genre de périphérique (le rev) qui est un disque sans en être un. (Sur une install récente, sur un HP Proliant 150, le fournisseur a essayé 3 rev (sata, ide, scsi) avant de fournir, à ma demande, une solide DAT72, et c'était sous Windows). Je préfère un bon lecteur DAT (et sa carte scsi) ou un disque USB(2) (en IDE). Cela fonctionne très bien pour faire des sauvegardes.

(Avec les disques USB, mes scripts de sauvegarde commence d'abord par un démontage puis remontage, et finissent par le démontage du disque : commandes umount et mount. Sans cela, on ne sait pas bien où on en est, à cause du automount.)

par **trixel** » 13 Sep 2007 10:05

merci pour cette réponse rapide.

pour la commande mount, y'a-t-il des commandes spécifiques à mettre pour un lecteur REV ?

le problème est bien que cela ne se produit pas à chaque fois, mais quand cela se produit c vraiment au début de la sauvegarde

par **trixel** » 13 Sep 2007 10:18

ok je viens de refaire la manip en rajoutant un umount et mount, j'ai ces 3 lignes qui se sont rajoutées :

Code: Tout sélectionner: Sep 13 09:56:43 serveur kernel: UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'REV 35', timestamp 2005/03/02 23:08 (1078) Sep 13 09:56:45 serveur kernel: cdrom: This disc doesn't have any tracks I recognize! Sep 13 09:59:13 serveur kernel: UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'REV 35', timestamp 2005/03/02 23:08 (1078)

puis la sauvegarde a commencé puis le serveur planté !!!

Autre question en cas de plantage on peut pas lui demander de redémarrer automatiquement ? car si je refais des tests la nuit je suis à distance

par **trixel** » 13 Sep 2007 10:21

puis pendant que j'y suis avec mes questions, n'est il pas possible de le formatter avec un autre format vu qu'apparemment le pb vient d'UDF ?

par **jdh** » 13 Sep 2007 10:35

Je ne connais pas bien ce matériel (vendu sous la référence RD1000 par Dell par exemple).

Le type de file system "udf" est celui de cdrom (comme iso9660), ce qui en principe facilite par nature les montages/démontages, mais ne facilite pas l'écriture (un cdrom est plutôt destiné à la lecture, même si udf est un format spécifiquement destiné à "ajouter" des données sessions par sessions à un CD-R par exemple).

Le (bon) type de file system disque est plutôt "ext3". Par exemple, avec un disque USB, le systeme usb-storage, au branchement du disque, créé des devices du type /dev/sdX (normalement utilisé par les disques SCSI ou sata). Ces devices sont partitionables normalement avec fdisk ou cfdisk, les partitions pouvant contenir ensuite des file system ext3, fat32 (vfat), ...

Peut-on faire pareil avec des Rev ? Je l'ignore.

Si j'étais face à ce pb, je regarderai ce qui survient dans /var/log/syslog (par un tail -f), au moment de l'introduction de la cartouche Rev. Peut-être y trouverais je, une idée sur les modules et devices mis en jeu.

Plantage serveur

Plantage serveur

Qui est en ligne ?