Hva gjør denne prosessen?

[zoomsalabim]

Fant en prosess på en av serverene mine som skriver:

 

dd if=/dev/zero of=/dev/null bs=1M

 

Jeg hadde skjønt det om of var en disk, men hvorfor vil noen overskrive /dev/null med /dev/zero??? Er det bare noen som har rotet på tastaturet og fått feil piper i forsøk på å ødelegge noe?

[Djn]

Det ser litt ut som en enkel måte å bruke opp CPU-tid - jeg vil tro det tar 100% av en kjerne?

[Emancipate]

Sikkert noen som har ment å teste om de husket syntaksen til dd før de satte i gang med noe viktig. Så fikk de ikke drept prosessen etterpå.

[Sokkalf™]

Funker som en litt primitiv måte å teste minnehastighet på, men det virker litt fjollete å bare la den kjøre "forever"

[zoomsalabim]

Sikkert noen som har ment å teste om de husket syntaksen til dd før de satte i gang med noe viktig. Så fikk de ikke drept prosessen etterpå.

 

Kan virke som dette er svaret. Så litt nedover i server-hierarkiet, og der lå en slik prosess med dd dev/null men med of mot en av de fysiske diskene i raidet (softwareraid md). bash_history var satt til /dev/null . Virker ikke som audit logget kommandoer heller.

[Sprokket]

Eneste jeg vet om som /dev/null gjør er at den sletter inneholdet du skriver. Rapporterer alltid True og hvis du lister ut innholdet får du EOF

[Gavekort]

dd if=/dev/zero of=/dev/null bs=1M

 

dd: Bitwise kopiering

if: Input fil

/dev/zero: En uendelig stream av null-characters

of: Output fil

/dev/null: Void - altså ingen steder, eller "slett"

bs: block size (batch størrelse)

1M: 1 MegaByte

 

Med andre ord så kopierer den en virtuelt uendelig stream av nuller til en void med 1MB batcher.

[j--]

 

Sikkert noen som har ment å teste om de husket syntaksen til dd før de satte i gang med noe viktig. Så fikk de ikke drept prosessen etterpå.

 

Kan virke som dette er svaret. Så litt nedover i server-hierarkiet, og der lå en slik prosess med dd dev/null men med of mot en av de fysiske diskene i raidet (softwareraid md). bash_history var satt til /dev/null . Virker ikke som audit logget kommandoer heller.

 

Lyst til å utdype dette litt? Ligger det en kjørende prosess som skriver til en fysisk disk i ett MDADM-oppsett? Eller er det noen som har kjørt kommandoen tidligere (som er lite trolig, ettersom .bashrc symlinker til /dev/null?)?

[zoomsalabim]

Det lå en kjørende dd if dev null of /dev/sdx altså den fysiske disken, ikke partisjon (var 1 bak i raidoppsett på alle de 4 diskene) Slike starter ikke av seg selv, så noen har hatt det gøy på den serveren.

 

Regner med at alle data er borte på den disken, så lar raidet bygge seg opp med en tom disk. Raid5 skal vel gi meg ett fungerende system. Ser likevel ut som luringen som bestemte seg for å lage arbeid har ødelagt mer, filsystemet som lå på raidet virker å ha blitt skadet så det holder.

[zoomsalabim]

For å følge opp litt. Vedkommende som kjørte kommandoen var en betrodd medarbeider, som fikk beskjed om å forlate arbeidsplassen tidligere samme dag. Han hadde åpnet en vei inn i systemet noen dager tidligere. Vedkommende tilstod i varetekt. Saken ble ekspressbehandlet av staten og vedkommende fikk dom på 90 dager, halvparten betinget. Vedkommende ble også dømt til å betale en erstatning som ikke er i nærheten av den skaden som ble påført selskapet. Så vidt jeg vet er det ikke avgjort om vedkommende eller staten kommer til å anke.

 

Argumentasjonen var at vedkommende bare ville vise hvor avhengige vi var av ham. Og at skaden var gjenopprettelig. Raid5 skulle sikre at data ikke gikk tapt når disken ble overskrevet.

 

Problemet er bare at det ikke er slik mdadm virker. Å skrive med dd til fysisk disk er ikke en feil så langt kernel ser på dette. Da blir ikke disken feilet, og mdadm oppdager ikke at noe er feil. Data blir overskrevet og filsystemet korrupteres. Dette er også nevnt i dokumentasjonen til mdadm. Teorien om at man skal kunne feile systemet manuelt ved å fjerne disken som har feil har jeg lite tro på. 

[tingo]

Og derfor: raid (uansett hvilken) er ikke backup / sikkerhetskopi og kommer aldri til å bli det.

[Occi]

Takk for oppdatering, kjekt å bli minnet på om at slikt kan skje.