---

Hej

Jeg har en Samba-daemon på min server som er løbet løbsk ..... Den står
og bruger 100% cputid.

Har prøvet med en kill -s 15 <processnr> - men den fortsætter bare.

Hvad gør jeg? Den skulle gerne stoppes inden den får hele serveren i
knæ...
--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
Gartneriet - http://www.gartneriet.dk/

---

On Sat, 28 Feb 2009 11:30:45 +0100
Mads Lie Jensen <mads@gartneriet.dk> wrote:

> Har prøvet med en kill -s 15 <processnr> - men den fortsætter bare.
>
kill -9 <processnr>

--
Hilsen/Regards
Michael Rasmussen
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

On Sat, 28 Feb 2009 11:42:55 +0100, Michael Rasmussen <mir@miras.org>
wrote:

>> Har prøvet med en kill -s 15 <processnr> - men den fortsætter bare.
>>
>kill -9 <processnr>

Det hjælper ikke
Processen fortsætter bare - med samme pid, så det er ikke engang fordi
den bliver genstartet af noget.

Er der så kun en reboot tilbage?
--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
Gartneriet - http://www.gartneriet.dk/

---

Mads Lie Jensen wrote:
> On Sat, 28 Feb 2009 11:42:55 +0100, Michael Rasmussen <mir@miras.org>
> wrote:
>
>>> Har prøvet med en kill -s 15 <processnr> - men den fortsætter bare.
>>>
>> kill -9 <processnr>
>
> Det hjælper ikke
> Processen fortsætter bare - med samme pid, så det er ikke engang fordi
> den bliver genstartet af noget.
>
> Er der så kun en reboot tilbage?

Hvad med 'sudo kill -9 ... '?


--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk

---

On Sat, 28 Feb 2009 12:49:43 +0000, Jørgen Heesche <heesche@webspeed.dk>
wrote:

>>>> Har prøvet med en kill -s 15 <processnr> - men den fortsætter bare.
>>>>
>>> kill -9 <processnr>
>>
>> Det hjælper ikke
>> Processen fortsætter bare - med samme pid, så det er ikke engang fordi
>> den bliver genstartet af noget.
>>
>> Er der så kun en reboot tilbage?
>
>Hvad med 'sudo kill -9 ... '?

Når en 'kill -9 <pid>' som root ikke du'r, så gør det vel ingen forskel?

Nu er maskinen blevet rebootet - eller, dvs. jeg måtte hårdt og brutalt
trykke på reset-knappen. Load på maskinen steg voldsomt og 'shutdown -r
now' ville den heller ikke.
--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
Gartneriet - http://www.gartneriet.dk/

---

Den Sat, 28 Feb 2009 11:53:59 +0100 skrev Mads Lie Jensen:
> On Sat, 28 Feb 2009 11:42:55 +0100, Michael Rasmussen <mir@miras.org>
> wrote:
>
>>> Har prøvet med en kill -s 15 <processnr> - men den fortsætter bare.
>>>
>>kill -9 <processnr>
>
> Det hjælper ikke

Hvad står state til ("S"-kolonnen i top)?

De eneste eksempler jeg har set på sådan en process har haft state
"D" - uninterruptible sleep. Det betyder den venter på et eller andet,
typisk en form for I/O.

Det kan fx være en disk der er ved at stå af, men en sikker måde at
få state D er at mounte et NFS-drev uden timeout, starte en process
der bruger NFS-drevet, og så slukke NFS-serveren.

Har man så oven i købet en cronjob der checker den mount'ede disk
hvert 5. minut, så vokser "loadavg" med 1 hver gang jobbet kører

Hvis det er et NFS-drev den er gal med, er løsningen at tænde NFS-
serveren igen. Er det fx en harddisk der er ved at stå af, er
løsningen en ny disk.

> Er der så kun en reboot tilbage?

Reboot er noget man gør med Windows-maskiner

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

On 01 Mar 2009 01:05:22 GMT, Kent Friis <nospam@nospam.invalid> wrote:

>>>kill -9 <processnr>
>>
>> Det hjælper ikke
>
>Hvad står state til ("S"-kolonnen i top)?

Det lå jeg ikke mærke til

>De eneste eksempler jeg har set på sådan en process har haft state
>"D" - uninterruptible sleep. Det betyder den venter på et eller andet,
>typisk en form for I/O.
>
>Det kan fx være en disk der er ved at stå af, men en sikker måde at
>få state D er at mounte et NFS-drev uden timeout, starte en process
>der bruger NFS-drevet, og så slukke NFS-serveren.
>
>Har man så oven i købet en cronjob der checker den mount'ede disk
>hvert 5. minut, så vokser "loadavg" med 1 hver gang jobbet kører
>
>Hvis det er et NFS-drev den er gal med, er løsningen at tænde NFS-
>serveren igen. Er det fx en harddisk der er ved at stå af, er
>løsningen en ny disk.

Det er diske i samme maskine - ikke noget NFS.
Loadavg. voksede stille og roligt - ikke i større hak.

>> Er der så kun en reboot tilbage?
>
>Reboot er noget man gør med Windows-maskiner

Tjo .. men når man står og skal ud af døren og _ved_ at maskinen vil gå
død i løbet af et par timer, fordi man ikke kan få dræbt den ene process
......

--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
Gartneriet - http://www.gartneriet.dk/

---

Den Sun, 01 Mar 2009 09:11:12 +0100 skrev Mads Lie Jensen:
> On 01 Mar 2009 01:05:22 GMT, Kent Friis <nospam@nospam.invalid> wrote:
>
>>>>kill -9 <processnr>
>>>
>>> Det hjælper ikke
>>
>>Hvad står state til ("S"-kolonnen i top)?
>
> Det lå jeg ikke mærke til

Det er en af ulemperne ved reboot som fejlsøgning.

>>De eneste eksempler jeg har set på sådan en process har haft state
>>"D" - uninterruptible sleep. Det betyder den venter på et eller andet,
>>typisk en form for I/O.
>>
>>Det kan fx være en disk der er ved at stå af, men en sikker måde at
>>få state D er at mounte et NFS-drev uden timeout, starte en process
>>der bruger NFS-drevet, og så slukke NFS-serveren.
>>
>>Har man så oven i købet en cronjob der checker den mount'ede disk
>>hvert 5. minut, så vokser "loadavg" med 1 hver gang jobbet kører
>>
>>Hvis det er et NFS-drev den er gal med, er løsningen at tænde NFS-
>>serveren igen. Er det fx en harddisk der er ved at stå af, er
>>løsningen en ny disk.
>
> Det er diske i samme maskine - ikke noget NFS.
> Loadavg. voksede stille og roligt - ikke i større hak.

En løbsk process kan ikke lave en load på over 1.

>>> Er der så kun en reboot tilbage?
>>
>>Reboot er noget man gør med Windows-maskiner
>
> Tjo .. men når man står og skal ud af døren og _ved_ at maskinen vil gå
> død i løbet af et par timer, fordi man ikke kan få dræbt den ene process

Og hvor ved "man" det fra?

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis <nospam@nospam.invalid> writes:

>> Det er diske i samme maskine - ikke noget NFS.
>> Loadavg. voksede stille og roligt - ikke i større hak.

>En løbsk process kan ikke lave en load på over 1.

Men årsagen bag kan fremprovokere det. Hvis en disk er ved at dø, kan
man ende i en ond cirkel, hvor flere og flere processer og/eller tråde
sidder fast. Det vil kunne skabe en masse context switches, og kernel
begynder at æde al CPU-tiden til at foretage dem. Hvilket gør at der
ophobes en vældig run-queue til den tilbageværende CPU-tid.

>> Tjo .. men når man står og skal ud af døren og _ved_ at maskinen vil gå
>> død i løbet af et par timer, fordi man ikke kan få dræbt den ene process

>Og hvor ved "man" det fra?

Det er tilladt at være doven

Den med "man rebooter ikke en Unix-boks" er også forældet. Den var
fin i gamle dage, hvor der ikke var SLA'er, og hvor man alligevel
ikke rigtig havde travlt, fordi ingen anede, hvad en sysadm lavede.

Men hvis man mister x kunder i timen, x kroner i timen eller bare
helt privat må bløde 500 kr for en taxa i stedet for 50 kr til
toget, fordi man bliver forsinket... så er en reboot da et rigtigt
godt bud på en professionelt afvejet løsning.

Hvis problemet senere gentager sig, er det naturligvis fornuftigt
at opveje risikoen for flere nedbrud mod prisen for at fejlsøge
ordentligt én gang for alle.

Mvh.
   Klaus.

---

Den Sun, 1 Mar 2009 12:53:19 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> Det er diske i samme maskine - ikke noget NFS.
>>> Loadavg. voksede stille og roligt - ikke i større hak.
>
>>En løbsk process kan ikke lave en load på over 1.
>
> Men årsagen bag kan fremprovokere det. Hvis en disk er ved at dø, kan
> man ende i en ond cirkel, hvor flere og flere processer og/eller tråde
> sidder fast.

Ja, og så er det netop at laod'en stiger med 1 hver gang der er
en process mere der hænger fast.

> Det vil kunne skabe en masse context switches,

Context-switches til processer der ikke laver noget, fordi de venter
på svar fra en død disk?

> og kernel
> begynder at æde al CPU-tiden til at foretage dem. Hvilket gør at der
> ophobes en vældig run-queue til den tilbageværende CPU-tid.
>
>>> Tjo .. men når man står og skal ud af døren og _ved_ at maskinen vil gå
>>> død i løbet af et par timer, fordi man ikke kan få dræbt den ene process
>
>>Og hvor ved "man" det fra?
>
> Det er tilladt at være doven
>
> Den med "man rebooter ikke en Unix-boks" er også forældet. Den var
> fin i gamle dage, hvor der ikke var SLA'er, og hvor man alligevel
> ikke rigtig havde travlt, fordi ingen anede, hvad en sysadm lavede.
>
> Men hvis man mister x kunder i timen, x kroner i timen eller bare
> helt privat må bløde 500 kr for en taxa i stedet for 50 kr til
> toget, fordi man bliver forsinket... så er en reboot da et rigtigt
> godt bud på en professionelt afvejet løsning.

Problemet med en reboot er at fejlen kommer igen på et eller andet
tidspunkt - og Murphy sørger for at næste gang har man endnu mindre
tid.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis <nospam@nospam.invalid> writes:

>> Det vil kunne skabe en masse context switches,

>Context-switches til processer der ikke laver noget, fordi de venter
>på svar fra en død disk?

Det kommer helt an på, hvordan disken er død. Det er klart, at hvis
den ender i en enkelt I/O-operation, der er blocked, så bliver den
ikke scheduled igen. Men hvis requests "bare" fejler, får du en byge
af nye requests og dermed uendeligt mange cs. Det kan sådan set bare
være driveren selv, der genererer dem, men det vil ikke se helt så
voldsomt ud.

Det er svært at sige, hvad der er sket i den konkrete situation,
især når vi ikke har noget vmstat. Men det roligt stigende load
tyder netop på noget opbyggende kø et sted.

>> Men hvis man mister x kunder i timen, x kroner i timen eller bare
>> helt privat må bløde 500 kr for en taxa i stedet for 50 kr til
>> toget, fordi man bliver forsinket... så er en reboot da et rigtigt
>> godt bud på en professionelt afvejet løsning.

>Problemet med en reboot er at fejlen kommer igen på et eller andet
>tidspunkt - og Murphy sørger for at næste gang har man endnu mindre
>tid.

Hvad hvis det var en enkeltstående fejl? Er det værd at bruge 450 kr
på som privat eller 100 millioner kroner som et stort firma? I de
fleste tilfælde vil det være formålstjenligt at sige, "oh well, lad
os se om det sker igen", hvis løsningen ikke ligger lige for.

Det er klart, at man ikke behøver at ignorere det, indtil det sker
igen. Man kan boote og så gå i gang med at undersøge sagen. I det
konkrete tilfælde om der netop skulle være en disk, der er på vej
til at stå af.

I andre tilfælde kan man måske straks bygge et lille script, der
kigger på diverse kernel logs, *stat, top ig så videer. Afhængig
af situationen kan det enten begynde at køre straks eller ligge
klar til situationen opstår igen.

I andre situationer kan man lave en regel om, at der er "råd" til
15 minutters fejlsøgning. Hvis problemet ikke er løst inden for
den tid, booter man. Om det lige skal være 15 minutter, kommer i
sagens natur an på det enkelte miljø.

Mvh.
   Klaus.

---

Den Sun, 1 Mar 2009 13:22:24 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> Det vil kunne skabe en masse context switches,
>
>>Context-switches til processer der ikke laver noget, fordi de venter
>>på svar fra en død disk?
>
> Det kommer helt an på, hvordan disken er død. Det er klart, at hvis
> den ender i en enkelt I/O-operation, der er blocked, så bliver den
> ikke scheduled igen. Men hvis requests "bare" fejler, får du en byge
> af nye requests og dermed uendeligt mange cs. Det kan sådan set bare
> være driveren selv, der genererer dem, men det vil ikke se helt så
> voldsomt ud.
>
> Det er svært at sige, hvad der er sket i den konkrete situation,
> især når vi ikke har noget vmstat. Men det roligt stigende load
> tyder netop på noget opbyggende kø et sted.
>
>>> Men hvis man mister x kunder i timen, x kroner i timen eller bare
>>> helt privat må bløde 500 kr for en taxa i stedet for 50 kr til
>>> toget, fordi man bliver forsinket... så er en reboot da et rigtigt
>>> godt bud på en professionelt afvejet løsning.
>
>>Problemet med en reboot er at fejlen kommer igen på et eller andet
>>tidspunkt - og Murphy sørger for at næste gang har man endnu mindre
>>tid.
>
> Hvad hvis det var en enkeltstående fejl?

Jeg kan ikke mindes hvornår jeg sidst har set sådan en. De kommer
altid igen.

> Er det værd at bruge 450 kr
> på som privat eller 100 millioner kroner som et stort firma?

100 millioner kroner? På at finde fejlen, i stedet for at
lukke hele firmaet ned i de 30-40 minutter det kan tage en server
at reboote, fordi en enkelt process hænger - i håb om at hvis det
er en disk der er defekt, så bliver den nok perfekt igen bare
fordi man rebooter?

> Det er klart, at man ikke behøver at ignorere det, indtil det sker
> igen. Man kan boote og så gå i gang med at undersøge sagen.

Fx checke i top om der står D ud for state, som jeg startede med
at spørge om? Hvordan vil du gøre det når fejlen er midlertidigt
væk?

> I det
> konkrete tilfælde om der netop skulle være en disk, der er på vej
> til at stå af.

Og hvis det er et netværksdrev?

> I andre situationer kan man lave en regel om, at der er "råd" til
> 15 minutters fejlsøgning. Hvis problemet ikke er løst inden for
> den tid, booter man. Om det lige skal være 15 minutter, kommer i
> sagens natur an på det enkelte miljø.

Det lyder altså som den berømte "nine fives" uptime.

15 minutters fejlsøgning på en enkelt process der hænger, og ser
dum ud, og måske en enkelt bruger der ikke kan lave noget, hvorefter
man vælger at lukke det hele ned i 30-40 minutter... Og dagen efter
kommer fejlen igen, fordi den samme idiot har mountet det samme
nfs-share og slukket sin PC.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis <nospam@nospam.invalid> writes:

>> Hvad hvis det var en enkeltstående fejl?

>Jeg kan ikke mindes hvornår jeg sidst har set sådan en. De kommer
>altid igen.

Hvor mange kværne er det, du drifter til dagligt?

Jeg er oppe på et par tusinde UNIX-bokse, og vi ser masser af den
slags. Mine skriverier er baseret på mange års erfaring emd real-
world, large-scale drift af temmeligt store maskiner.

>> på som privat eller 100 millioner kroner som et stort firma?

>100 millioner kroner?

Overdrivelse fremmer forståelsen. Men selv hvis det var 100.000
kroner, er det så en okay udgift for at problem, der viser sig
aldrig at komme igen alligevel, når du kunne nøjes med at "betale"
1.000 kr?

Hvis du bliver sat på en vagtordning, og dine kolleger kan løse
flere problemer hurtigere ved at reboote, end du kan ved at lave
fejlsøgning under nedetid, hvor hurtigt bliver du så fyret igen?

>Det lyder altså som den berømte "nine fives" uptime.

Det kan være en del af det koncept, ja. Men det er også et spørgsmål
om, at hvis ét ud af 20 alvorlige problemer kan løses ved at boote
og fejlsøge bagefter, så er det bedre end at bruge tid på at løse
det, mens tjenesten er nede.

Uanset hvilken metode, man vælger, så er der noget cost-benefit inde
i billedet. Reboots er i praksis slet ikke nogen tosset plan, men
det er naturligvis ikke nogen universal-løsning, og det er ganske
begrænset, hvad man bruger reboots til.

Jeg siger jo ikke, at man bare skal lukke øjnene og reboote. Jeg
siger, at det i en række tilfælde kan være en udmærket løsning
blandt flere. Især for private fnidder-servere hvor eneste ulempe
ved ekstra nedetid er, at netradioen går i stykker.

>15 minutters fejlsøgning på en enkelt process der hænger, og ser
>dum ud, og måske en enkelt bruger der ikke kan lave noget, hvorefter
>man vælger at lukke det hele ned i 30-40 minutter...

Eller 30 sekunder? Hvorfor skal det tage 30 minutter at boote en
kværn? Bevares, hvis det er noget enterprise-gear, tager det den
mængde tid, men i så fald har man sikkert noget HA-cluster inde i
billedet alligevel og kan holde nedetiden på nogle få minutter.

Mvh.
   Klaus.

---

Den Sun, 1 Mar 2009 14:27:32 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> Hvad hvis det var en enkeltstående fejl?
>
>>Jeg kan ikke mindes hvornår jeg sidst har set sådan en. De kommer
>>altid igen.
>
> Hvor mange kværne er det, du drifter til dagligt?

Det bør ikke gøre nogen forskel mht. fordelingen imellem
"pålidelige fejl" (90%) og fejl der ikke kommer igen efter
en reboot (max 10%)

> Jeg er oppe på et par tusinde UNIX-bokse, og vi ser masser af den
> slags. Mine skriverier er baseret på mange års erfaring emd real-
> world, large-scale drift af temmeligt store maskiner.

Det lyder som om i kører et generelt ustabilt system. Hvad så
end det er hardwaren eller softwaren.

> Overdrivelse fremmer forståelsen. Men selv hvis det var 100.000
> kroner, er det så en okay udgift for at problem, der viser sig
> aldrig at komme igen alligevel, når du kunne nøjes med at "betale"
> 1.000 kr?
>
> Hvis du bliver sat på en vagtordning, og dine kolleger kan løse
> flere problemer hurtigere ved at reboote, end du kan ved at lave
> fejlsøgning under nedetid, hvor hurtigt bliver du så fyret igen?

Nu har jeg en chef der gerne vil have sikkerhed for at det ikke
sker igen. Og det får man kun hvis man ved hvad problemet var.

>>Det lyder altså som den berømte "nine fives" uptime.
>
> Det kan være en del af det koncept, ja. Men det er også et spørgsmål
> om, at hvis ét ud af 20 alvorlige problemer kan løses ved at boote
> og fejlsøge bagefter, så er det bedre end at bruge tid på at løse
> det, mens tjenesten er nede.

Og så skidt med at man rebooter 20 gange hvor det kun løste problemet
den ene gang, og de andre 19 er bare 19 * 30 minutters fuldstændig
spildt nedetid, for man skal alligevel til at finde fejlen bagefter?

>>15 minutters fejlsøgning på en enkelt process der hænger, og ser
>>dum ud, og måske en enkelt bruger der ikke kan lave noget, hvorefter
>>man vælger at lukke det hele ned i 30-40 minutter...
>
> Eller 30 sekunder? Hvorfor skal det tage 30 minutter at boote en
> kværn?

Det gjorde det nemt på HP/UX'erne. De Intel-servere vi har hvor
jeg arbejder nu kan vel klare den på 5-10 minutter, medmindre
selvfølgelig det er over 30 dage siden der har været kørt fsck...

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis <nospam@nospam.invalid> writes:

>Det lyder som om i kører et generelt ustabilt system. Hvad så
>end det er hardwaren eller softwaren.

Skal vi ikke bare blive enige om, at du ikke har nogen drifterfaring
i stor stil, og at vi ikke bliver enige om, hvordan man professionelt
løser driftproblemer?

Så kan læserne selv finde ud af, hvem de helst vil lytte til.

Mvh.
   Klaus.

---

Den Sun, 1 Mar 2009 14:41:02 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>Det lyder som om i kører et generelt ustabilt system. Hvad så
>>end det er hardwaren eller softwaren.
>
> Skal vi ikke bare blive enige om, at du ikke har nogen drifterfaring
> i stor stil,

Du foretrækker åbenbart "gå efter manden, ikke efter bolden"-
argumentationsteknikken...

> og at vi ikke bliver enige om, hvordan man professionelt
> løser driftproblemer?

Nu skriver du "løser", men du har indtil nu argumenteret for at
reboote og se om symptomet forsvinder af sig selv, fremfor at
løse problemet.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis <nospam@nospam.invalid> writes:

>> Skal vi ikke bare blive enige om, at du ikke har nogen drifterfaring
>> i stor stil,

>Du foretrækker åbenbart "gå efter manden, ikke efter bolden"-
>argumentationsteknikken...

I det omfang, at den ene side argumenterer uden at have nævneværdig
praktisk erfaring om emnet, så vil tillade mig at gøre opmærksom på
det. Hvis en sådan nøgtern konstatering er at "gå efter manden", så
ja.

Det væsentlige her er jo, at der er tale om en vurdering fra sag
til sag. Hvis der ikke er noget impact ved at fejlsøge, så er det
naturligvis vigtigt at gøre. Hvis der er et impact, er det vigtigt
at vurdere nedetid kontra reel benefit ved fejlsøgning kontra en
kvalificeret satsning på en hurtig omgåelse.

Hvornår er man i stand til det? Når man ikke har lavet andet i et
par år, så bliver det en hel del lettere. Man rammer naturligvis
ved siden af nu og da, men det er mere undtagelsen end reglen.

Her er det jo så, at den ene parts manglende erfaring kommer ind i
billedet. Hvorfor skulle det være kontroversielt at påpege?

Mvh.
   Klaus.

---

On 01 Mar 2009 12:36:17 GMT, Kent Friis <nospam@nospam.invalid> wrote:

>>>Hvad står state til ("S"-kolonnen i top)?
>>
>> Det lå jeg ikke mærke til

>Det er en af ulemperne ved reboot som fejlsøgning.

Nu e den så gal igen .... der står 'R' i state-kolonnen. Og at den
bruger 100% cpu.

>> Det er diske i samme maskine - ikke noget NFS.
>> Loadavg. voksede stille og roligt - ikke i større hak.
>
>En løbsk process kan ikke lave en load på over 1.

"noget" gør at loadavg bare stiger. Det eneste som er anderledes er
denne ene smbd-process som pludselig æder 100% cpu.

>> Tjo .. men når man står og skal ud af døren og _ved_ at maskinen vil gå
>> død i løbet af et par timer, fordi man ikke kan få dræbt den ene process
>
>Og hvor ved "man" det fra?

Jeg har oplevet et par morgener på det sidste at maskinen ikke har været
til at komme i kontakt med.
Jeg har en Cacti til at køre og lave fine grafer over div. ting, bl.a
load avg. De dage maskinen ikke har villet snakke med mig, kan jeg se at
load avg har været ekstremt højt, inden maskinen også holdt op med at
lave graferne.
--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
Gartneriet - http://www.gartneriet.dk/

---

Den Sun, 01 Mar 2009 18:28:53 +0100 skrev Mads Lie Jensen:
> On 01 Mar 2009 12:36:17 GMT, Kent Friis <nospam@nospam.invalid> wrote:
>
>>>>Hvad står state til ("S"-kolonnen i top)?
>>>
>>> Det lå jeg ikke mærke til
>
>>Det er en af ulemperne ved reboot som fejlsøgning.
>
> Nu e den så gal igen .... der står 'R' i state-kolonnen. Og at den
> bruger 100% cpu.

Så skal den kunne kill'es, om ikke andet med "kill -9".

Hvis det var mig, ville jeg checke med strace hvad den har gang i, men
det vil du nok ikke få noget ud af.

>>> Det er diske i samme maskine - ikke noget NFS.
>>> Loadavg. voksede stille og roligt - ikke i større hak.
>>
>>En løbsk process kan ikke lave en load på over 1.
>
> "noget" gør at loadavg bare stiger. Det eneste som er anderledes er
> denne ene smbd-process som pludselig æder 100% cpu.

Der er noget meget underligt på din PC.

Jeg begynder næsten at hælde til den med et root-kit - det ville også
forklare at den ikke kan kill'es.

>>> Tjo .. men når man står og skal ud af døren og _ved_ at maskinen vil gå
>>> død i løbet af et par timer, fordi man ikke kan få dræbt den ene process
>>
>>Og hvor ved "man" det fra?
>
> Jeg har oplevet et par morgener på det sidste at maskinen ikke har været
> til at komme i kontakt med.

Det sagde du jo ikk enoget om.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Mads Lie Jensen <mads@gartneriet.dk> writes:

>Nu e den så gal igen .... der står 'R' i state-kolonnen. Og at den
>bruger 100% cpu.

Det lyder på lidt googling som om Samba har fået sig en kernel task
- det kan forklare en hel del. Blandt andet hvorfor den ikke kan
slås ihjel.

Jeg har også fundet et forslag om at sørge for, at den ikke bliver
master browser. Det gøres ved at tilføje følgende i smb.conf:

   domain master = no
   local master = no
   preferred master = no
   os level = 0

Jeg har ikke nævneværdigt styr på Samba, så ovenstående er altså
blot et sammendrag af, hvad jeg fik ud af at lege med Google. Jeg
har ikke selv testet det.

Mvh.
   Klaus.

---

On Sun, 1 Mar 2009 18:03:10 +0000 (UTC), Klaus Ellegaard
<klausellegaard@msn.com> wrote:

>>Nu e den så gal igen .... der står 'R' i state-kolonnen. Og at den
>>bruger 100% cpu.
>
>Det lyder på lidt googling som om Samba har fået sig en kernel task
>- det kan forklare en hel del. Blandt andet hvorfor den ikke kan
>slås ihjel.
>
>Jeg har også fundet et forslag om at sørge for, at den ikke bliver
>master browser. Det gøres ved at tilføje følgende i smb.conf:
>
>   domain master = no
>   local master = no
>   preferred master = no
>   os level = 0
>
>Jeg har ikke nævneværdigt styr på Samba, så ovenstående er altså
>blot et sammendrag af, hvad jeg fik ud af at lege med Google. Jeg
>har ikke selv testet det.

Det forsøger jeg.
Jeg kan sa i smbd.log at noget gik galt da min windowsmaskine gik i
gulvet på den hårde måde. Derefter var det at samba løb løbsk. Med lsof
kunne jeg se hvilke filer den løbske proces havde fingrene i, men jeg
kunne stadig ikke slå den ihjel.

--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
Gartneriet - http://www.gartneriet.dk/

---

On Sun, 1 Mar 2009 18:03:10 +0000 (UTC), Klaus Ellegaard
<klausellegaard@msn.com> wrote:

>Mads Lie Jensen <mads@gartneriet.dk> writes:
>
>>Nu e den så gal igen .... der står 'R' i state-kolonnen. Og at den
>>bruger 100% cpu.
>
>Det lyder på lidt googling som om Samba har fået sig en kernel task
>- det kan forklare en hel del. Blandt andet hvorfor den ikke kan
>slås ihjel.

<klip>

>Jeg har ikke nævneværdigt styr på Samba, så ovenstående er altså
>blot et sammendrag af, hvad jeg fik ud af at lege med Google. Jeg
>har ikke selv testet det.

Det hjalp ikke i længden - men jeg fandt nu i stedet denne:
https://bugzilla.novell.com/show_bug.cgi?id=475998 - det lader til at
være en kernel-bug hos SuSE. Jeg har nu opgraderet til den kernel de
anbefaler der - håber det hjælper.

--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
Gartneriet - http://www.gartneriet.dk/

---

Mads Lie Jensen wrote:

> Hvad gør jeg? Den skulle gerne stoppes inden den får hele serveren i
> knæ...

$ sudo /etc/init.d/samba restart

Det burde stoppe alle smbd processer og disconnecte klienterne.

--
Jesper Lund

---

On 28 Feb 2009 14:57:06 GMT, Jesper Lund <usenet@jesperlund.com> wrote:

>> Hvad gør jeg? Den skulle gerne stoppes inden den får hele serveren i
>> knæ...
>
>$ sudo /etc/init.d/samba restart
>
>Det burde stoppe alle smbd processer og disconnecte klienterne.

Jeg havde lavet en /etc/init.d/samba stop

Og jeg kunne efterfølgende fint starte samba igen, og det virkede. Men
den ene process blev hængende, og slugte 100% cpu. Og jeg kunne ikke slå
den ihjel.

Nu er samba så blevet opdateret til en lidt nyere (kørte før med den som
er som standard i SUSE 11.1).
Maskinen har nemlig et par gange den sidste måned været helt i knæ, uden
at jeg kunne komme i kontakt med den, og jeg kan se at Load har været
over 60 de gange - men uden at finde ud af hvad det skyldtes.

--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
Gartneriet - http://www.gartneriet.dk/

---

> Nu er samba så blevet opdateret til en lidt nyere (kørte før med den
> som er som standard i SUSE 11.1).
> Maskinen har nemlig et par gange den sidste måned været helt i knæ,
> uden at jeg kunne komme i kontakt med den, og jeg kan se at Load har
> været over 60 de gange - men uden at finde ud af hvad det skyldtes.
sidst jeg havde tilsvarende problem er godt nok nogle år siden men ---
det viste sig den var hacket med et rootkit ;(

så check lige!

finn

---

On Sat, 28 Feb 2009 14:29:42 +0100, Mads Lie Jensen wrote:

> Nu er maskinen blevet rebootet - eller, dvs. jeg måtte hårdt og brutalt
> trykke på reset-knappen. Load på maskinen steg voldsomt og 'shutdown -r
> now' ville den heller ikke.

Det der samba er noget djævelskab. Dit problem ligner hvad jeg oplevede
da jeg brugte samba for omkring fem år siden. Det var en fejl jeg så hvis
jeg af en eller anden grund fik trukket netstikket ud.


Tomas

---

Klaus Ellegaard <klausellegaard@msn.com> writes:

> Eller 30 sekunder? Hvorfor skal det tage 30 minutter at boote en
> kværn? Bevares, hvis det er noget enterprise-gear, tager det den
> mængde tid, men i så fald har man sikkert noget HA-cluster inde i
> billedet alligevel og kan holde nedetiden på nogle få minutter.

En ting er maskinen, noget andet den applikationskode der ligger
ovenpå. Det er heldigvis ikke normen på de systemer jeg har hotline
på, men vi har nogle stykker, hvor bare en genstart af applikationen
kommer op i omegnen af 20 minutter.

--
/Wegge