Forum Mjukvara Linux och övriga operativsystem Tråd

Hur få mina !"#¤ diskar att gå standby vid start?

1
Skriv svar
Permalänk
Avstängd
●

Hur få mina !"#¤ diskar att gå standby vid start?

Har ett litet enkelt problem jag trodde skulle vara löst med enkla medel, men nej, nu har jag brottats med detta i två dagar.

Jag har en backupserver ("headless") med Debian som har flera hårddiskar. /, /boot och /home är på en OS-disk (sda) och den får gärna köra dygnet runt.

Men de andra diskarna kommer bara användas ett par timmar i veckan, är inte mountade vid start och kör dessutom luks. Det finns alltså ingen anledning att dessa skulle vara igång 24/7 utan kan gott och väl vara avstängda tills de behövs, någon timme en gång i veckan.

Diskarna är WD-diskar och dessa lyssnar inte riktigt på hdparm, speciellt APM-nivåer kan inte ställas in.

Detta gör ingenting, för diskarna lyssnar utmärkt på kommandot "hdparm -y /dev/sd*" och stänger ner sig fint. Eftersom diskarna är omountade vid boot finns det heller inget som drar igång dem, så ett hdparm -y (standby-kommandot) kommer låta aktuell disk att vara avstängd ända tills den den mountas.

Bekymret är att Debian vägrar stänga av diskarna vid boot. Jag har stoppat in kommandot "hdparm -y ...", först i rc.local, sedan i ett eget skript aktiverat med update-rc.d, osv, osv.

Ingenting händer och när jag tittar i syslog så står det ett meddelande, något i stil med "cannot shut down sdb during boot" eller liknande (ska kolla syslog-meddelandet noga sedan och uppdatera inlägget).

Eftersom ingen heller kommer logga in på servern speciellt ofta, kan jag inte lägga skriptet i någon användares loginskript och dessutom är det inte önskvärt att diskar stängs av för att någon loggar in.

Så, hur ska jag göra för att köra "hdparm -y /dev/sdX" (där X är b, c, d, etc och diskar som INTE ens är mountade vid start) på ett sätt där datorn
1) faktiskt kör detta och varvar ner diskarna
2) inte varvar upp diskarna automatiskt igen en halv sekund senare på grund av någon dum process vid uppstart
?

Jag vill alltså på något sätt exekvera hdparm det absolut sista som sker i uppstart innan loginprompten, men något som *bara* sker vid uppstart (under användning har jag full koll på diskarna).

Och, som sagt, dessa diskar lyssnar inte på hdparm -S eller -B, men -y fungerar fint.

Edit: Meddelandet i syslog är "Failed to start LSB: Tries to shut down sdb at boot time". Vad linux anbelangar är sdb, sdc, osv råa, tomma enheter med noll skrivningar eller läsningar till. De är inte mountade, de omnämns inte i fstab och de ska banne mig varva ner vid uppstart! Jag tolkar meddelandet som att något inte riktigt vill att hårddiskar ska spinna ner vid boot eftersom "något annat kanske vill accessa dessa".

Hur får jag ett kommando att köras efter all "bootning", men innan login?

Senast redigerat
Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Redigera
Citera flera Citera
Permalänk
Avstängd
●

Ok. Det verkar ha löst sig. Det är ju kutym att posta lösningar eftersom andra kan ha samma problem.

Bekymret är att jag inte riktigt vet varför det plötsligt fungerar.
Jag gjorde iaf ett skript som ser ut så här:

#!/bin/sh
### BEGIN INIT INFO
# Provides:		hdparmcommands
# Required-Start:	$remote_fs $syslog
# Required-Stop:	$remote_fs $syslog
# Default-Start:	2 3 4 5
# Default-Stop:		0 1 6
# Short-Description:	Tries to shut down sdb at boot time
### END INIT INFO

# Spin down secondary drives
/sbin/hdparm -y /dev/sdb
/sbin/hdparm -y /dev/sdc
/sbin/hdparm -y /dev/sdd
/sbin/hdparm -y /dev/sde

Skriptet fick heta "hdparmcommands" och lades i /etc/init.d/
Sedan körde jag "update-rc.d hdparmcommands defaults 1000"
Jag vill att skriptet ska köras så sent som möjligt så inte andra idiotprocesser accessar sekundära diskar så de startar igen. Jag antar att "1000" gör att det hamnar senare, jag har förstått det som att siffran är någon sorts prioriteringsordning där 1 körs före 2, osv. Men säker är jag inte.

Efter att ha ändrat någon enstaka byte här och där i skriptet så verkar det nu fungera. Till en början hette skriptet "hdparmcommands.sh", men det gick minsann inte. Nåväl, det verkar fungera nu, diskarna är avstängda vilket jag ser på strömförbrukningen (har en effektmätare inkopplad, eftersom jag förbereder en server som ska kunna nås 24/7 men som ändå bara kommer ha ett par timmars arbete per vecka är det viktigt att minimera strömförbrukningen). Även hdparm -C /dev/sdX rapporterar diskarna som "standby", vilket är bra!

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

En fullösning är att lägga typ "sleep 5m" med i service-scriptet innan första hdparm. För jag antar att du inte har så bråttom med att stänga av diskarna så snabbt som möjligt? Och 5 minuter efter normal start så lär ju allt definitivt vara fullt uppstartat varje gång.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

@MBY:

Rent generellt, är det inte vettigare att använda uuid istället för device names när man vill sätta sådana parametrar vid boot på moderna system?

Mig veterligen är det där LSB-tjohejet inte jättegammalt i Debian, och dessutom kanske något av en kompromiss i vissa hänseenden. Är inte tillräckligt insatt för att kunna förklara det utan att i alla fall delvis komma med en massa sakfel, så det låter jag bli, men läs på lite om det själv, så gissar jag på att samma tankegångar väcks hos dig som hos mig, att det faktiskt på något sätt vore rimligt att blockera den där sortens inskjutande av parametrar tills bootsekvensen är klar.

Dold text

Glöm det inom spoiler. Är inte tillräckligt nykter för att formulera budskapet jag vill få fram riktigt.

Man skulle förresten kunna köra ett litet fulhack med Required-Start. Släng in något lämpligt där, som inte är igång förrän diskarna garanterat är klara att ta emot dina kommandon. Typ mountdevsubfs eller nåt sånt.

Senast redigerat
Visa signatur

Nu lurade jag dig att slösa bort ett par värdefulla sekunder av ditt liv på att läsa denna fullständigt poänglösa signatur!

Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag kör Debian, men har inte velat göra samma sak som dig. Däremot vill jag nämna att för mig får mina diskar olika namn vid i princip varje start, dvs det som är sda vid ena starten kan nästa start lika gärna vara sdb. Det enda sättet att veta vilken som är vilken är för mig att gå via deras UUID. Men det är kanske inte en del av ditt problem? Att du försöker spinna ner systemdisken av misstag vid boot med ditt script?

Visa signatur

Akta så att du inte trillar i drickat!

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Webbe:

Jag kör Debian, men har inte velat göra samma sak som dig. Däremot vill jag nämna att för mig får mina diskar olika namn vid i princip varje start, dvs det som är sda vid ena starten kan nästa start lika gärna vara sdb. Det enda sättet att veta vilken som är vilken är för mig att gå via deras UUID. Men det är kanske inte en del av ditt problem? Att du försöker spinna ner systemdisken av misstag vid boot med ditt script?

Gå till inlägget

Jotack, det där minns jag, och det var just precis det fenomenet som fick mig att börja jobba med diskar via uuid istället för device names, det fuckade ju runt rätt bra när man hade för vana att köra med device names i /etc/fstab Det började i Debian 6 eller något.

Har för vana att installera om från scratch när ny major version av Debian kommer, och fenomenet uppträdde bara en major. Det är inte så att du råkar sitta på en installation du uppgraderat genom åren utan att någonsin installera om?

Visa signatur

Nu lurade jag dig att slösa bort ett par värdefulla sekunder av ditt liv på att läsa denna fullständigt poänglösa signatur!

Redigera
Citera flera Citera
Permalänk
Medlem
●

@kaput: Jo, jag kör en en installation som är "åldrad"(kan väl vara från 2007 ursprungligen), men det beror nog inte på det. Jag har även kört senaste versionen installerad från scratch med i stort sett samma hårdvara nyligen med samma resultat. Däremot har jag hyfsat många diskar och kontrollerkort (7st olika kretsar tror jag om man räknar de som är integrerade på moderkortet) vilket ökar risken att diskarna byter namn mellan omstarterna. Men det är väl så här Linuxkärnan är tänkt att fungera nuförtiden? Vill man vara säker får man använda UDEV-regler och utnyttja enheternas UUID.

För mig spelar det oftast ingen roll, men för dem som gör som du skriver och monterar diskar efter deras /dev/sdX-beteckning kan det bli rätt spännande i filsystemet.

Senast redigerat
Visa signatur

Akta så att du inte trillar i drickat!

Redigera
Citera flera Citera
Permalänk
Avstängd
●

Haha, nu när problemet är löst, ja då drar tråden igång!

Skrivet av kaput:

@MBY:

Rent generellt, är det inte vettigare att använda uuid istället för device names när man vill sätta sådana parametrar vid boot på moderna system?

Gå till inlägget

Jovisst, men orka. De diskarna kommer inte springa i väg och byta plats eller enumreras om. Och även om så sker kommer sda förbli systemdisken och *alla* de andra diskarna ska ner.

Om jag ska ha uuid så måste jag ju köra ett kommando till för att få dessa och antingen skriva ner eller pipa in dessa i skriptfilen. Ren lathet alltså. Nu funkar det till synes fint och jag tänker inte "fixa" något som inte är trasigt!

Webbe: Enda gången jag ser att diskar enumreras olika i /dev är om man bootar på andra medier, t.ex. USB eller live-CD. Annars brukar inte diskar flytta runt och speciellt inte sda. Och, som sagt, det spelar ingen roll vilka diskar som enumreras till exakt vad, de ska ner, allihop! Att ta ner systemdisken vore förstås onödigt, men antar att den genast skulle starta upp igen.

Om jag stöter på bekymmer i framtiden så får jag väl använda uuids i stället.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

@Webbe:

Åhå, där ser man. För mig var det bara en enda version av Debian, den första efter att den förändringen infördes, där det var devicenamelotto. Efter det tycks det återigen ordnas in efter vilka sataportar diskarna sitter på. Har dock fortsatt köra operationer mot diskarna via uuid just in case, så mycket bökigare är det inte. Typ dunka in storagediskarna i fstab och fixa nedspinningsscript ungefär. Engångsgrejer

@MBY:

Haha, isn't that always the way? Nä, men tänkte att det kanske var något intermittent fel, problem på OS-nivå brukar sällan försvinna automagiskt sådär mellan två omklotningar.

Tycker dock fortfarande inte det vore otippat om dskarna får sina device names senare initieringen än de får uuid:s - som sagt inte superinsatt i Linux bootsekvens, speciellt som den ändrats hit och dit genoom åren - och att det därmed kanske är en bra idé att köra med uuid:s för att minimera risken för krockar.

Visa signatur

Nu lurade jag dig att slösa bort ett par värdefulla sekunder av ditt liv på att läsa denna fullständigt poänglösa signatur!

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Ser att det har löst sig redan men funderar på om inte hdparm.conf borde kunna användas, t.ex genom:

/dev/sdb {
    standby
}

Använder det själv för att ange spindown_time (motsvarigheten till -S). Fungerar bra förutom att filen ej läses in efter en hibernate.

Visa signatur

Efter att ni har läst det här har ni insett att det inte gav något.

Redigera
Citera flera Citera
1
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara