Existe-t-il une commande équivalente pour «init.d / networking restart» sous OS X

17

De temps en temps, j'ai rencontré des problèmes avec les connexions réseau des clients OS X (filaire et sans fil, Leopard / Snow Leopard) où rien ne résoudra le problème, jusqu'à ce que vous redémarriez.

Existe-t-il un «service / processus réseau» particulier que je devrais surveiller?
Je pensais qu'il serait utile de connaître une commande qui réinitialisera un service / processus de type 'connexion réseau' (identique à l'exécution d'un redémarrage sudo /etc/init.d/networking).

Après un dépannage de base tel que DHCP, DNS, vérification du dysfonctionnement de l'interface (désactiver / activer), vérification des journaux et ne pas trouver suffisamment d'informations utiles, parfois lorsque tout le reste échoue, la meilleure chose à faire est simplement de redémarrer la machine. Je ne sais pas ce que fait tout le «redémarrage init.d / mise en réseau» sous Linux, mais je sais que c'est beaucoup plus utile que de désactiver et d'activer les interfaces.

Merci!

— l0c0b0x
source

1

Vous dites que «rien» ne résoudra le problème ... pouvez-vous nous dire ce que vous avez essayé et qui n'a pas fonctionné?

— TCampbell

Hehehe, à peu près tout à ma portée ... et ça n'a pas été un problème, ça a été beaucoup ... encore une fois, avec et sans fil. Par exemple, j'ai vu un problème où la carte réseau ne réagit PAS, même après la désactivation et l'activation (sur deux machines différentes avec des versions différentes d'OS X et des modèles différents). Je ne demanderais pas ceci si les problèmes n'étaient pas aléatoires :)

— l0c0b0x

Avez-vous réussi à comprendre comment faire fonctionner le réseau à nouveau sans redémarrer, j'ai le même problème. La chose vraiment étrange est que j'exécute Windows dans VMWare et que j'ai toujours la connectivité réseau de la session VMWare.

2

Pour être franc, votre question est un peu comme aller chez le médecin et dire: «Je suis malade, donnez-moi des médicaments qui me guériront». Le redémarrage /etc/init.d/networking supprime fondamentalement l'interface, la soulève à nouveau, puis applique l'adressage configuré. Certains pilotes de carte Ethernet réinitialisent la carte chaque fois qu'elle est soulevée. C'est peut-être pourquoi le redémarrage du réseau a si bien fonctionné pour vous. Mon point est, si vous voulez une réponse valable, pouvez-vous vous concentrer sur l'exemple le plus irritant de cela? Est-ce que toutes vos situations sont au même endroit par exemple? Est-ce que "problèmes" signifie "ne charge pas les pages Web?"

— etherfish

1

J'ai eu une version encore plus noueuse. De temps en temps, tout le réseau tombe. Les beachballs déroulants wifi et sur le panneau Network System Prefs la liste sur le côté est vide. Il n'y a même pas de "wifi" pour redémarrer. ifconfig est vide, pas même un bouclage localhost. Un redémarrage de /etc/init.d/network serait plutôt agréable, mais peut-être qu'avec la machine dans cet état, un redémarrage est précisément ce qui est nécessaire. Sur lunix, je peux recharger les modules du noyau, redémarrer le réseau, toutes sortes de choses bien documentées. quand le fidèle ol 'maccenbox obtient ce chemin, techniquement appelé "chier le lit", je tire la prise :(

— Shayne

19

Vous pouvez désactiver l'interface réseau et la réactiver, cela devrait accomplir la même chose.

sudo ifconfig en0 down
sudo ifconfig en0 up

— Martin M
source

2

Je pense que ce serait la même chose que d'aller dans pref / panel et de désactiver le périphérique et de le réactiver, non? (qui, bien sûr, j'ai essayé).

— l0c0b0x

J'ai beaucoup plus d'interfaces réseau que en0. Ce n'est pas vraiment équivalent à la question posée.

— gman

11

Non, il n'y a pas d'init.d / service / launchctl équivalent à 'init.d / networking'.

Si c'est lié au wifi, vous pouvez pousser l'interface depuis la ligne de commande (sur SL) avec: /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport

S'il est câblé, utilisez ifconfig.

Autre que cela ... je vérifierais dmesg et / var / log / * pour les erreurs.

Vous pouvez également décharger / recharger le kld ou le vérifier pour les erreurs .., et le recharger, mais je n'ai jamais essayé, je préfère simplement redémarrer. :)

Voir:

kextfind (8) - rechercher des extensions de noyau (kexts) en fonction de divers critères et imprimer des informations
kextload (8) - charger des extensions de noyau (kexts) dans le noyau
kextunload (8) - terminer les instances de pilote du kit d'E / S du pilote et décharger le noyau extensions (kexts)
kextutil (8) - charger, diagnostiquer les problèmes et générer des symboles pour les extensions du noyau (kexts)

— Essobi
source

1

+1 pour la réponse «liée au noyau».

— l0c0b0x

8

Si vous voulez le faire depuis un shell / distant ssh:

sudo ifconfig <interface> down;sleep 1;sudo ifconfig <interface> up

— Bluetouque
source

3

Si un simple ifconfigmontée / descente ne fonctionne pas, créez un «emplacement» supplémentaire sur lequel tous les périphériques réseau sont désactivés, puis exécutez-le scutilpour y basculer, dormez quelques secondes, puis ramenez-le.

Cela dit, je n'ai vu cela se produire sur aucun de mes Mac, sauf lorsque le serveur DHCP a eu un ajustement et que cela a coïncidé avec le renouvellement du bail (et donc le Mac a fini par être mal configuré). La configuration réseau est-elle réellement correcte lorsque cela se produit? S'ils sont DHCP'd, le fait de cliquer sur le bouton "Renouveler" dans les Préférences Réseau> {Périphérique}> TCP / IP a-t-il un effet? Qu'en est-il, dans le cas du sans-fil, de la mise hors et sous tension de l'aéroport? Si vous pouvez découvrir ce qui, en plus d'un redémarrage, le ramènera, alors vous êtes un grand pas en avant pour déterminer ce qui déclenche réellement le comportement - le frapper avec un gros bâton (c'est ce qui fait rebondir les interfaces efficacement), ne va jamais affecter les symptômes, pas la cause.

— Mo.
source

Ajout d'informations supplémentaires à la question. Oui, dans ce cas (ce matin), DHCP fonctionnait bien, tout comme DNS. Je recherche l'étape «si tout échoue» qui n'inclut pas un redémarrage du système d'exploitation.

— l0c0b0x

1

sur Linux, à /etc/init.d/networking stoppeu près fait juste ifconfig ethX downpour chaque interface. cela pourrait également vider la table de routage et éventuellement vider le cache ARP. la magie est dans la startcommande, pas dans le stop- et tout ce qui ne fait que configurer l'adressage et les routes (ou renouveler le bail DHCP, le cas échéant) si le module de périphérique réseau est déjà présent. Le redémarrage est très très très rarement le meilleur plan d'action.

— Mo.

pour clarifier - lorsque vous dites que DHCP et DNS fonctionnent correctement, la sortie depuis ifconfiget arpsur les machines clientes est-elle la même que dans des circonstances normales? vos commutateurs peuvent-ils les atteindre, même s'ils ne peuvent pas voir d'autres choses sur le réseau? pour que cela se produise assez souvent (et dans des conditions aussi variées) pour que vous posiez la question, je regarderais une partie de l'infrastructure autre que les clients eux-mêmes, en toute honnêteté.

— Mo

C'est peut-être principalement ce à quoi j'essaie de répondre ici, ce que l'arrêt / le démarrage du réseau fait réellement pour vous ... et comment vous pouvez faire de même sur OSX. Dans ce cas, la machine OSX a pu acquérir une adresse IP, mais pas se connecter à un point d'accès pour l'authentification / portail actif (l'association allait bien), j'aurais dû faire un tcpdump pour savoir où le COM se cassait, mais a décidé pour redémarrer et cela semblait "résoudre" le problème. Ma préoccupation est que j'ai eu des problèmes avant que même la désactivation / l'activation d'une carte réseau n'ait pas fait «l'affaire», lors du redémarrage.

— l0c0b0x

ok… l'équivalent le plus proche networking restart est de désactiver / activer les interfaces - c'est ce que font ces scripts shell. donc, si cela ne fait pas l'affaire, c'est un problème de pilote ou de matériel. Étant donné que cela se produit sur un tas de machines différentes sur différentes versions de système d'exploitation, filaire et sans fil, le seul véritable facteur commun est l'infrastructure à laquelle ils se connectent.

— Mo.

1

J'ai eu le même problème (le réseau a commencé à être lent après quelques heures, je travaille principalement sur un Mac connecté par un réseau câblé à un ordinateur Windows) et ce qui a fonctionné pour moi a été d'éjecter l'ordinateur auquel j'étais connecté (dans le Finder) et désactivez Ethernet (Préférences Système -> Réseau -> Ethernet -> Désactivé), puis reconnectez-les. :)

— Pedro Laia
source