4 votes

Stu Thompson avatar

Prévention des points de montage AFP "fantômes".

Demandé el 4 de Février, 2010
Quand la question a-t-elle été
3647 affichage
Nombre de visites la question a
1 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Nous avons un problème avec les clients OSX 10.6 qui voient des points de montage "fantômes" sur un serveur OSX 10.5 via AFP. À l'occasion (5 fois au cours du dernier mois), la machine cliente semble avoir un problème de connexion avec le serveur et remonte le partage. Le Finder semble correct pendant tout ce processus, mais en /Volumes/ l'ancien montage reste en tant que répertoire, et un nouveau point apparaît en /Volumes/ avec un suffixe incrémentiel ; par exemple :

lrwxr-xr-x   1 root    admin    1 Feb  3 12:39 Macintosh HD -> /
dr-x------@  9 cutter  staff  264 Jun  4  2008 Produktion
drwxrwxr-x  10 cutter  staff  408 Jan  5 07:44 Simplex TimeMachine
dr-x------@  7 cutter  staff  264 Jun  4  2008 Transfer
drwxr-xr-x+  3 cutter  admin  102 Jan 13 14:24 Voyager
drwxr-xr-x+  3 cutter  admin  102 Jan 18 10:28 Voyager-1
drwxr-xr-x+  3 cutter  admin  102 Jan 25 09:20 Voyager-2
drwxr-xr-x+  3 cutter  admin  102 Jan 25 16:31 Voyager-3
drwxr-xr-x+  3 cutter  admin  102 Feb  3 08:30 Voyager-4
drwx------@ 10 cutter  staff  296 Jan 13 13:12 Voyager-5

Mais le Finder montre aux utilisateurs un partage normal de type "Voyager" et rien n'indique qu'il y ait un quelconque problème.

Bug du Finder OSX http://www.dietpizza.ch/images/finder-bug.png

Alors que le Finder permet aux gens de naviguer vers le fichier cible sur le partage (nous "voyons" le fichier en question). /Voyager/myfile.txt ), tout chemin de fichier utilisé dans notre logiciel a le suffixe numéroté (comme /Voyager-5/myfile.txt ). Une fois que le point de montage est remonté avec un nouveau suffixe ( /Voyager-6 ), l'ancien chemin devient invalide. Notre logiciel garde une référence permanente au fichier, et quand il essaie d'y accéder, boom ! Mais pour l'utilisateur qui regarde le Finder, il n'y a pas de problème apparent.

J'ai grep J'ai cherché des indices dans les journaux du système, mais je n'ai pas l'impression d'avoir beaucoup d'éléments :

manoa:Logs stu$ grep mount *
system.log.4:Feb  3 08:53:33 Streaming1-MacPro fseventsd[38]: check_vol_last_mod_time:XXX failed to get mount time (25; &mount_time == 0x10043f8b8)
system.log.4:Feb  3 09:31:44 Streaming1-MacPro UnmountAssistant[811]: Volume unmounted successfully
system.log.5:Feb  2 09:28:56 Streaming1-MacPro UnmountAssistant[10763]: Volume unmounted successfully
system.log.6:Feb  1 12:26:17 Streaming1-MacPro UnmountAssistant[2277]: 
system.log.7:Jan 28 13:54:05 Streaming1-MacPro fseventsd[38]: check_vol_last_mod_time:XXX failed to get mount time (25; &mount_time == 0x10077f8b8)
system.log.7:Jan 28 13:55:34 Streaming1-MacPro UnmountAssistant[27673]: Volume unmounted successfully
system.log.7:Jan 28 13:55:36 Streaming1-MacPro UnmountAssistant[27673]: Volume unmounted successfully

y grep pour l'horodatage du dernier "fantôme" de l'action :

system.log.4:Feb  3 08:30:33 localhost com.apple.launchd[1]: *** launchd[1] has started up. ***
system.log.4:Feb  3 08:30:37 localhost mDNSResponder[17]: mDNSResponder mDNSResponder-214 (Oct 16 2009 06:09:30) starting
system.log.4:Feb  3 08:30:38 Streaming1-MacPro configd[15]: setting hostname to "Streaming1-MacPro.local"
system.log.4:Feb  3 08:30:38 Streaming1-MacPro configd[15]: network configuration changed.
system.log.4:Feb  3 08:30:42 Streaming1-MacPro bootlog[44]: BOOT_TIME: 1265182233 0
system.log.4:Feb  3 08:30:45 Streaming1-MacPro configd[15]: network configuration changed.
system.log.4:Feb  3 08:30:46 Streaming1-MacPro com.apple.usbmuxd[26]: usbmuxd-176 built for iTunesNineDot on Sep 24 2009 at 16:11:05, running 32 bit
system.log.4:Feb  3 08:30:46 Streaming1-MacPro configd[15]: network configuration changed.
system.log.4:Feb  3 08:30:46 Streaming1-MacPro com.intego.commonservices.daemon[53]: Using preferences format 3
system.log.4:Feb  3 08:30:46 Streaming1-MacPro com.apple.SystemStarter[27]: Starting Qmaster services
system.log.4:Feb  3 08:30:47 Streaming1-MacPro blued[45]: Apple Bluetooth daemon started
system.log.4:Feb  3 08:30:47 Streaming1-MacPro /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow[34]: Login Window Application Started
system.log.4:Feb  3 08:30:49 Streaming1-MacPro loginwindow[34]: Login Window Started Security Agent
system.log.4:Feb  3 08:30:49 Streaming1-MacPro WindowServer[72]: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
system.log.4:Feb  3 08:30:49 Streaming1-MacPro com.apple.WindowServer[72]: Wed Feb  3 08:30:49 Streaming1-MacPro.local WindowServer[72] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.

Il y a des trucs de réseau là-dedans, mais rien d'effrayant.

Il y a quelques informations sur The Intertubes concernant des problèmes similaires, et la plupart des gens semblent dire :

  • Démonter le partage
  • Supprimer les anciens dossiers/partages restant dans /Volumes/
  • Redémarrer
  • Ajouter une action en retour

Ces machines fonctionnent généralement 24 heures sur 24 et 7 jours sur 7 dans une salle de presse, et je dis à mes utilisateurs de production faites simplement ces quatre tâches techniques, et tout ira bien pendant quelques jours/semaines, et vous devrez recommencer à un moment donné". ne passe pas très bien.

Je voudrais une solution permanente - ces volumes fantômes devraient disparaître et ne jamais revenir !

Informations sur le client :

La sortie de mount :

/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk1s2 on /Volumes/Simplex TimeMachine (hfs, local, nodev, nosuid, journaled)
afp_4gqctq000egI0000oM0000VU-1.2d000003 on /Volumes/Produktion (afpfs, nodev, nosuid, mounted by cutter)
afp_4gqctq000egI0000oM0000VU-2.2d000004 on /Volumes/Voyager-5 (afpfs, nodev, nosuid, mounted by cutter)
afp_4gqctq000egI0000oM0000VU-3.2d000005 on /Volumes/Transfer (afpfs, nodev, nosuid, mounted by cutter)

Des extraits de profil système apparemment pertinents :

  Model Identifier:              MacPro4,1
  Processor Name:                Quad-Core Intel Xeon
  Processor Speed:               2.66 GHz
  Number Of Processors:          2
  Memory:                        8 GB
  Boot ROM Version:              MP41.0081.B03
  SMC Version (system):          1.39f5
  SMC Version (processor tray):  1.39f5

  Type:         afpfs
  Mount Point:  /Volumes/Voyager-5
  Automounted:  No

Informations sur le serveur :

Des extraits de profil système apparemment pertinents :

  Model Identifier:     Xserve1,1
  Processor Name:       Dual-Core Intel Xeon
  Processor Speed:      2.66 GHz
  Number Of Processors: 2
  Boot ROM Version:     XS11.0080.B03
  SMC_version:          1.11f5
  LOM Revision:         1.2.8

Fibre Channel Domain 2:
  Vendor:   LSILogic
  Product:  LSI7404EP
  Revision: Firmware 1.3.14.0
  Speed:    2 Gigabit

SCSI Target Device @ 0:
  Manufacturer: APPLE
  Model:        Xserve RAID
  Revision:     1.50
SCSI Logical Unit @ 0:    
  Capacity:           2,18 TB
  Manufacturer:       APPLE
  Model:              Xserve RAID
  Revision:           1.50
  Mac OS 9 Drivers:   No
  Partition Map Type: APM (Apple Partition Map)
  Volumes:
R_Xraid-Mars:
  Capacity:      2,18 TB
  Writable:      Yes
  File System:   Journaled HFS+
  Mount Point:   /Volumes/R_Xraid-Mars
Demandé el 4 de Février, 2010 par Stu Thompson

Réponse

Trop de publicités?

1voto

xenoterracide avatar
xenoterracide Points 596

La cause est probablement spécifique à l'une de vos applications.

Pour nous, c'était lié à Vectorworks 2008. Il s'agit d'une application multiplateforme qui semble conserver sa propre copie du répertoire actuel dans la boîte de dialogue Enregistrer/Ouvrir, sans utiliser les fonctionnalités du système OS X pour cela. Nous avons déjà trouvé d'autres bogues liés à des chemins non encodés (par exemple, les utilisateurs mettent des barres obliques dans le nom du fichier, ce qui est interprété comme un séparateur de chemin, etc.)

Les étapes à reproduire étaient les suivantes :

  1. Naviguez vers le serveur dans la boîte de dialogue Ouvrir/Enregistrer de Vectorworks.
  2. Quitter l'application
  3. Déconnexion du serveur
  4. Nettoyez /Volumes et ouvrez une fenêtre du Finder sur /Volumes pour surveiller les nouveaux fantômes.
  5. Démarrer la demande
  6. Utilisez Fichier > Ouvrir et regardez un partage fantôme se créer dès que la boîte de dialogue Ouvrir/Enregistrer apparaît. Notez qu'à ce stade, nous ne sommes pas connectés au serveur, donc la boîte de dialogue Ouvrir/Enregistrer se réoriente vers le répertoire personnel de l'utilisateur.

Le partage fantôme qui est créé à l'étape 6 a le même suffixe numérique que le dernier partage réel, ce qui nous suggère fortement qu'il s'agit d'un problème de code interne à l'application. Par exemple, si la dernière connexion réelle était "Active Projects-4", l'application créera un dossier -4, mais la reconnexion au serveur créera un point de montage avec -5, ou autre.

Je suppose que vous devrez faire des essais et des erreurs avec votre combinaison d'applications. Un conseil : il nous a été fortement suggéré de regarder Vectorworks lorsque nous avons examiné le contenu de ces partages fantômes. Les nôtres étaient des sous-dossiers imbriqués dans un chemin qui ne contenait généralement que des documents Vectorworks (c'est-à-dire ce que l'on obtient avec l'option mkdir -p /path/to/subfolder ).

Répondu el 25 de Novembre, 2010 par xenoterracide (596 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X