Le blog de ​​Michael OSS / Linux, réseau et ma vie privée

15 Aug/10 0

Économie d'énergie de suspendre serveur de fichiers avec

Après un temps éternel maintenant pour moi exécuté un serveur de 24x7, j'ai décidé d'éliminer progressivement le dès maintenant et pour construire une option plus économes en énergie. Peut objectif était d'avoir un serveur de fichiers, en utilisant Wake-on-LAN se réveiller et de ne pas fonctionner en permanence. C'était important pour moi le plus rapidement possible et de se réveiller le serveur, qui veut attendre longtemps pour accéder aux documents.

Pour résoudre le problème est maintenant la gestion d'une Debian Lenny avec le dernier noyau de backports.

  chiot: ~ # uname-r
 2.6.32-amd64-bpo.5 

Seule la mise à niveau du noyau a permis de réduire les fonctions d'économie d'énergie activées (en particulier cpufreq) la consommation d'environ 20 watts.

En outre, je veux que le serveur n'est pas toujours arrêter manuellement à, alors je suis allé à la recherche d'un vérificateur, qui est déjà vérifie d'une part si quelqu'un est connecté via SSH, d'autre part le réseau, les suspects habituels pour les contrôles d'activité afin d'assurer que le serveur n'est pas arrêté en cas de besoin.
J'ai trouvé ce que j'étais dans le "serveur sleepd", a apparemment été construit par le Heise à temps partiel trouver le script shell est sous http://mercurial.intuxication.org/hg/server-sleepd .
Dans le script, on peut distinguer ce qu'il faut faire avec le serveur lors de l'arrêt, dans mon cas, "h-suspendre» est appelé à l'endormir.

J'ai eu des problèmes mais le WOL, je n'ai pas été réveiller le serveur à nouveau. L'erreur est tout simplement un WOL deaktiverem sur la carte réseau et l'événement de réveil deaktivertem pour la carte réseau à la recherche de l'ACPI.

Si tous l'air comme suit:

  chiot: ~ # cat / proc / acpi / wakeup
 Dispositif état S Statut Sysfs noeud
 PS2K S4 désactivé pnp: 00:00 une
 UAR1 S4 désactivé pnp: 00:00 b
 NSMB S4 pci désactivé: 0000:00: 01.1
 USB0 S4 désactivé pci: 0000:00: 02.0
 USB2 S4 désactivé pci: 0000:00: 02,1
 NMAC S5 compatible pci: 0000:00: 07.0
 P0P1 S4 désactivé pci: 0000:00: 04,0
 HDAC S4 pci désactivé: 0000:00: 05.0
 BR10 S4 désactivé pci: 0000:00: 09,0
 BR12 S4 désactivé pci: 0000:00:0 c.0
 BR11 S4 désactivé pci: 0000:00:0 b.0
 chiot: ~ # ethtool eth0
 Réglages pour eth0:
	 Ports pris en charge: [MII]
	 Half 10baseT / Full Modes de liaison en charge: 10baseT / 10baseT Half / Full
	                         Full 100baseT / 100baseT Half / Full
	                         1000baseT / complet
	 Prend en charge la négociation automatique: Oui
	 Half 10baseT / Full Modes de liaison annoncés: 10BaseT / 10baseT Half / Full
	                         Full 100baseT / 100baseT Half / Full
	                         1000baseT / complet
	 Annoncées auto-négociation: Oui
	 Vitesse: 1000 Mo / s
	 Duplex: Full
	 Port: MII
	 PHYAD: une
	 Transceiver: external
	 Auto-négociation: le
	 Supporte le Wake-on: g
	 Wake-on: g
	 Link detected: yes 

Important ici est que dans / proc / acpi / wakeup dans la carte réseau respectif est "activé" apparaît dans l'état, sinon les événements de cette source ne sert pas à se réveiller.
L'ID PCI correcte de la carte réseau peut être trouvé via "lspci".

Est l'ensemble avec moi dans / etc / network / interfaces lors du démarrage des connexions réseau.

  jusqu'à ethtool-s eth0 voulez g
 gt; / proc / acpi / wakeup jusqu'à écho NMAC & gt; / proc / acpi / wakeup 

Filed under: elle , de noyau , Linux No Comments
10 Dez/09 0

rootdelay la botte Linux

Tout à l'heure que j'ai eu avec une toute nouvelle installation Linux, un problème pour la première fois le nouveau système. L'erreur n'était pas d'abord apparente, après une longue mise au point a montré l'erreur comme suit:

Au cours de la transition de l'initrd pour le noyau et le montage du système de fichiers a signalé l'erreur Grub:

ALERT! /dev/sda2 does not exist. Dropping to a shell!

Puis, j'ai été accueilli par un obus de BusyBox dont je n'ai malheureusement pas continuer.

Le problème était tout simplement le chargement du module contrôleur SAS (mptsas) prend le système trop longtemps pour trouver les plaques et s'interrompt avec un timeout.

L'erreur peut être expliqué par le paramètre

rootdelay=45

fixer dans la ligne de commande du noyau.

Voir aussi ici, au bord décrit.