---

På min linux maskine (gentoo) giver følgende kommando:

ls -l --sort=time /tmp

blandt en masse andet, følgende resultat:

-r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp1c7f4844.tmp
-r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp279a275f.tmp
-r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp300452ad.tmp
-r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp55727154.tmp
-r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp515a844a.tmp

Jeg kan ikke huske præcist hvornår jeg installerede systemet, men
det er ihvertfald efter 1970.
Hvordan kan jeg have filer liggende der angiveligt er fra 1.1.1970?

Ydermere kunne jeg godt bruge noget plads, er der nogen måde at se om
*.tmp filer i /tmp mappen stadig bruges? Eller skal man helt holde
fingrene fra /tmp?

mvh Kristian

---

Den Sun, 01 Apr 2007 16:24:07 +0000 skrev Kristian:
> På min linux maskine (gentoo) giver følgende kommando:
>
> ls -l --sort=time /tmp
>
> blandt en masse andet, følgende resultat:
>
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp1c7f4844.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp279a275f.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp300452ad.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp55727154.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp515a844a.tmp
>
> Jeg kan ikke huske præcist hvornår jeg installerede systemet, men
> det er ihvertfald efter 1970.
> Hvordan kan jeg have filer liggende der angiveligt er fra 1.1.1970?

Ved at det program der har lavet dem sætter en anden dato.

> Ydermere kunne jeg godt bruge noget plads, er der nogen måde at se om
> *.tmp filer i /tmp mappen stadig bruges? Eller skal man helt holde
> fingrene fra /tmp?

fuser /tmp/tmp*.tmp

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Sun, 01 Apr 2007 16:24:07 +0000, Kristian wrote:

> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp1c7f4844.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp279a275f.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp300452ad.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp55727154.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp515a844a.tmp

> Jeg kan ikke huske præcist hvornår jeg installerede systemet, men
> det er ihvertfald efter 1970.
> Hvordan kan jeg have filer liggende der angiveligt er fra 1.1.1970?

Unixlignende systemers tidsregning starter ofte 1/1-1970 ("unix
epoch"¹), så det du ser er sandsynligvis filer med tidsstemplet "0".

Det virker en lille smule kuriøst. De er også ganske store. Hvad er
der i dem?

> Ydermere kunne jeg godt bruge noget plads, er der nogen måde at se om
> *.tmp filer i /tmp mappen stadig bruges? Eller skal man helt holde
> fingrene fra /tmp?

lsof(8) - list open files, kan måske give et hint?


Mvh.

Adam


¹ <http://en.wikipedia.org/wiki/Epoch_%28reference_date%29#Computing>

--
"Det skulle vara lätt för mig at säga att jag inte Adam Sjøgren
hittar hem, men det gör jag; tror jag" asjo@koldfront.dk

---

On Sun, 01 Apr 2007 16:49:20 +0200, Adam Sjøgren wrote:

> On Sun, 01 Apr 2007 16:24:07 +0000, Kristian wrote:
>
>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp1c7f4844.tmp
>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp279a275f.tmp
>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp300452ad.tmp
>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp55727154.tmp
>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp515a844a.tmp
>
>> Jeg kan ikke huske præcist hvornår jeg installerede systemet, men
>> det er ihvertfald efter 1970.
>> Hvordan kan jeg have filer liggende der angiveligt er fra 1.1.1970?
>
> Unixlignende systemers tidsregning starter ofte 1/1-1970 ("unix
> epoch"¹), så det du ser er sandsynligvis filer med tidsstemplet "0".
>
> Det virker en lille smule kuriøst. De er også ganske store. Hvad er
> der i dem?
>

Tjaa jeg er på bar bund med hensyn til hvorfor de har fået tidsstemplet
"0", ls --sort=time angiver jo hvornår de blevet ændret. Der er ingen
programmer eller processer der bruger dem nu (ifølge lsof og fuser). Er
der en måde at se hvilket program der sidst har ændret en fil.

less /tmp/tmp1c7f4844.tmp producerer en meget lang tabel med hex tal, jeg
er ikke programmør så det siger ikke mig noget.

>> Ydermere kunne jeg godt bruge noget plads, er der nogen måde at se om
>> *.tmp filer i /tmp mappen stadig bruges? Eller skal man helt holde
>> fingrene fra /tmp?
>
> lsof(8) - list open files, kan måske give et hint?

jep, tak. Men alle de tmp*.tmp filer der ligger ubrugte hen i /tmp, kan de
bare slettes eller er der et program der forventer at finde dem?
Hvis de bare kan slettes burde programmerne så ikke rydde op efter sig
selv?

>
>
> Mvh.
>
> Adam
>
>
> ¹ <http://en.wikipedia.org/wiki/Epoch_%28reference_date%29#Computing>


Tak for hjælpen iøvrigt

mvh Kristian

---

Kristian <kristianbro5@hotmail.com> writes:

> On Sun, 01 Apr 2007 16:49:20 +0200, Adam Sjøgren wrote:
>
>> On Sun, 01 Apr 2007 16:24:07 +0000, Kristian wrote:
>>
>>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp1c7f4844.tmp
>>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp279a275f.tmp
>>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp300452ad.tmp
>>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp55727154.tmp
>>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp515a844a.tmp
>>
>>> Jeg kan ikke huske præcist hvornår jeg installerede systemet, men
>>> det er ihvertfald efter 1970.
>>> Hvordan kan jeg have filer liggende der angiveligt er fra 1.1.1970?
>>
>> Unixlignende systemers tidsregning starter ofte 1/1-1970 ("unix
>> epoch"¹), så det du ser er sandsynligvis filer med tidsstemplet "0".
>>
>> Det virker en lille smule kuriøst. De er også ganske store. Hvad er
>> der i dem?
>>
>
> Tjaa jeg er på bar bund med hensyn til hvorfor de har fået tidsstemplet
> "0", ls --sort=time angiver jo hvornår de blevet ændret. Der er ingen
> programmer eller processer der bruger dem nu (ifølge lsof og fuser). Er
> der en måde at se hvilket program der sidst har ændret en fil.
>
> less /tmp/tmp1c7f4844.tmp producerer en meget lang tabel med hex tal, jeg
> er ikke programmør så det siger ikke mig noget.
>
>>> Ydermere kunne jeg godt bruge noget plads, er der nogen måde at se om
>>> *.tmp filer i /tmp mappen stadig bruges? Eller skal man helt holde
>>> fingrene fra /tmp?
>>
>> lsof(8) - list open files, kan måske give et hint?
>
> jep, tak. Men alle de tmp*.tmp filer der ligger ubrugte hen i /tmp, kan de
> bare slettes eller er der et program der forventer at finde dem?
> Hvis de bare kan slettes burde programmerne så ikke rydde op efter sig
> selv?

Skal vi sige det på denne måde:

- der _plejer_ ikke at ligge sådan noget
- det ville være yderst dumdristigt af et program at tro at ting
bliver liggende i /tmp (det er ret normalt at systemet selv sletter
gamle filer der)
- filstørrelse og -dato ligner noget der er lavet ved en fejl

og jo programmer _burde_ rydde op, men dels er det ikke alle der gør
hvad de bør, dels kan det jo tænkes at programmet er blevet aflivet i
utide. Har du spurgt "bruger1" om han/hun kender noget til sagen? Hvis
ikke (fx. hvis det er dig selv...), så tror jeg at du med relativ stor
sindsro kan borteliminere dem væk.

--
O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907

---

Kristian wrote:
> På min linux maskine (gentoo) giver følgende kommando:
>
> ls -l --sort=time /tmp
>
> blandt en masse andet, følgende resultat:
>
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp1c7f4844.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp279a275f.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp300452ad.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp55727154.tmp
> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp515a844a.tmp
>
>
> Ydermere kunne jeg godt bruge noget plads, er der nogen måde at se om
> *.tmp filer i /tmp mappen stadig bruges? Eller skal man helt holde
> fingrene fra /tmp?
Man kan godt slette filer i /tmp, men der er selvfølgelig en risiko for
at et aktivt job skal bruge en given fil. Det bedste er at slette i /tmp
ved boot. I Mandriva kan man i Control Center sætte kryds ved et punkt
der hedder 'Clean /tmp at each boot'. Gentoo har sikkert en tilsvarende
funktion.

--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk
Linux user siden 1998

---

Jørgen Heesche wrote:
SKIP

> Man kan godt slette filer i /tmp, men der er selvfølgelig en risiko for
> at et aktivt job skal bruge en given fil. Det bedste er at slette i /tmp
> ved boot. I Mandriva kan man i Control Center sætte kryds ved et punkt
> der hedder 'Clean /tmp at each boot'. Gentoo har sikkert en tilsvarende
> funktion.
>
Der også et program, tmpwatch, som sletter gamle filer; kan køres
dagligt i et cronjob.
Se her: http://gentoo-wiki.com/HOWTO_clean_/tmp#Configuration_.28optional.29



--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk
Linux user siden 1998

---

On Sun, 01 Apr 2007 19:30:41 +0000, Jørgen Heesche wrote:

> Jørgen Heesche wrote:
> SKIP
>
>> Man kan godt slette filer i /tmp, men der er selvfølgelig en risiko for
>> at et aktivt job skal bruge en given fil. Det bedste er at slette i /tmp
>> ved boot. I Mandriva kan man i Control Center sætte kryds ved et punkt
>> der hedder 'Clean /tmp at each boot'. Gentoo har sikkert en tilsvarende
>> funktion.
>>
> Der også et program, tmpwatch, som sletter gamle filer; kan køres
> dagligt i et cronjob.
> Se her: http://gentoo-wiki.com/HOWTO_clean_/tmp#Configuration_.28optional.29

Hvad med:

&(
>for i in /tmp/tmp*.tmp
>do
> fuser $i || rm -f $i
>done
>)

burde det ikke virke

mvh Kristian

---

Kristian wrote:
> On Sun, 01 Apr 2007 19:30:41 +0000, Jørgen Heesche wrote:
>
>> Jørgen Heesche wrote:

SKIP

>
> Hvad med:
>
> &(
>> for i in /tmp/tmp*.tmp
>> do
>> fuser $i || rm -f $i
>> done
>> )
>
> burde det ikke virke
>
Jo, det kan det nok; men jeg mener tmpwatch er bedre. Tmpwatch kan
slette filer der ikke har været brugt i et vist antal timer.
'/usr/sbin/tmpwatch 240 /tmp ' sletter filer, der ikke har været brugt
i 240 timer. Tmpwatch har forøvrigt en fuser option: --fuser. Se man
tmpwatch.
"Attempt to use the "fuser" command to see if a file is already open
before removing it."

--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk
Linux user siden 1998

---

Du har ret, jeg har lige fået kigget på tmpwatch. Det er vist lige hvad
der skulle til. tak for hjælpen.

mvh Kristian

---

Den Sun, 01 Apr 2007 19:04:22 +0000 skrev Jørgen Heesche:
> Kristian wrote:
>> På min linux maskine (gentoo) giver følgende kommando:
>>
>> ls -l --sort=time /tmp
>>
>> blandt en masse andet, følgende resultat:
>>
>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp1c7f4844.tmp
>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp279a275f.tmp
>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp300452ad.tmp
>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp55727154.tmp
>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp515a844a.tmp
>>
>>
>> Ydermere kunne jeg godt bruge noget plads, er der nogen måde at se om
>> *.tmp filer i /tmp mappen stadig bruges? Eller skal man helt holde
>> fingrene fra /tmp?
> Man kan godt slette filer i /tmp, men der er selvfølgelig en risiko for
> at et aktivt job skal bruge en given fil. Det bedste er at slette i /tmp
> ved boot. I Mandriva kan man i Control Center sætte kryds ved et punkt
> der hedder 'Clean /tmp at each boot'. Gentoo har sikkert en tilsvarende
> funktion.

Og så have 15GB (5*3GB) spild liggende i /tmp indtil næste boot i 2012?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
> Den Sun, 01 Apr 2007 19:04:22 +0000 skrev Jørgen Heesche:
>> Kristian wrote:
>>> På min linux maskine (gentoo) giver følgende kommando:
>>>
>>> ls -l --sort=time /tmp
>>>
>>> blandt en masse andet, følgende resultat:
>>>
>>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp1c7f4844.tmp
>>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp279a275f.tmp
>>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp300452ad.tmp
>>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp55727154.tmp
>>> -r-------- 1 bruger1 hjem 3124806508 Jan 1 1970 tmp515a844a.tmp
>>>
>>>
>>> Ydermere kunne jeg godt bruge noget plads, er der nogen måde at se om
>>> *.tmp filer i /tmp mappen stadig bruges? Eller skal man helt holde
>>> fingrene fra /tmp?
>> Man kan godt slette filer i /tmp, men der er selvfølgelig en risiko for
>> at et aktivt job skal bruge en given fil. Det bedste er at slette i /tmp
>> ved boot. I Mandriva kan man i Control Center sætte kryds ved et punkt
>> der hedder 'Clean /tmp at each boot'. Gentoo har sikkert en tilsvarende
>> funktion.
>
> Og så have 15GB (5*3GB) spild liggende i /tmp indtil næste boot i 2012?
>
Ja, måske, hvis det er en computer, der kører i døgndrift. Men selv da,
er der ingen computer der kører uafbrudt så lang tid, så du sætter
sagen lidt på spidsen.
I stedet for 'clean at boot' kan man, som jeg anfører efterfølgende,
starte programmet tmpwatch i et cronjob.
På min hjemmepc, som bootes mindst een gang dagligt, fungerer systemet
fint. Jeg kan til gengæld ikke bruge cron-muligheden. Jeg kan forsåvidt
overhovedet ikke bruge cron til noget.

--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk
Linux user siden 1998

---

On Sun, 01 Apr 2007 19:58:22 +0000
Jørgen Heesche <heesche@webspeed.dk> wrote:

--SNIP--

> > Og så have 15GB (5*3GB) spild liggende i /tmp indtil næste boot i 2012?
> >
> Ja, måske, hvis det er en computer, der kører i døgndrift.. Men selv da,
> er der ingen computer der kører uafbrudt så lang tid, så du sætter
> sagen lidt på spidsen.

dette er en laptop (ThinkPad R50)

jag@jag-tpr50$ ud -d
- Uptime for jag-tpr50.btl.lan -
Now : 4 day(s), 17:51:31 running Linux 2.6.20.3
One : 1641 day(s), 20:28:00 running Linux 2.6.17.4, ended Tue Aug 1 11:22:33 2006
Two : 31 day(s), 03:13:40 running Linux 2.6.17.4, ended Mon Oct 2 01:40:28 2006
Three: 25 day(s), 21:55:21 running Linux 2.6.17.4, ended Wed Nov 15 14:49:22 2006
jag@jag-tpr50$


jeg har drevet og set set servere med oppetider på flere år



--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

Jacob Gaarde <-dont@dev.null> writes:

> Three: 25 day(s), 21:55:21 running Linux 2.6.17.4, ended Wed Nov 15 14:49:22 2006

> jeg har drevet og set set servere med oppetider på flere år

Så har det nok ikke være Linuxservere - der plejer at være god grund
til at opgradere kernen ind imellem.
--
Thorbjørn Ravn Andersen

---

On 02 Apr 2007 20:46:44 +0200, Thorbjørn Ravn Andersen wrote:

> Så har det nok ikke være Linuxservere - der plejer at være god grund
> til at opgradere kernen ind imellem.

Hvorfor det?
Jeg har svært ved at forstå hvorfor noget der virker og kører stabilt
skal opgraderes.
--
Leonard
http://leonard.dk/

---

Leonard <piper28a@gmail.com> writes:

>Hvorfor det?
>Jeg har svært ved at forstå hvorfor noget der virker og kører stabilt
>skal opgraderes.

Sikkerheds-patches?

Lidt afhængig af det givne scenarie kan man måske argumentere
for, at det ikke betyder så meget.

En anden detalje er, at jo længere systemer kører, desto større
er risikoen for, at det er svært at få dem op at køre, når de
endelig har været nede at vende.

Udfordringen dér er, at detaljer som /etc/fstab ikke er blevet
opdateret, men filsystemer bare er mounted i hånden ("den går
alligevel aldrig ned").

Jo længere sådan en maskine kører, desto flere af den slags
småproblemer risikerer der at opstå. Når skidtet så endelig
skal genstartes klokken 3 en morgen, er der måske 30 af den
slags problemer.

Medmindre man kan løse dem allesammen på et par minutter, er
det vist ikke i kategorien "virker og stabilt" mere.

Mvh.
   Klaus.

---

Den Mon, 2 Apr 2007 19:04:19 +0000 (UTC) skrev Klaus Ellegaard:
> Leonard <piper28a@gmail.com> writes:
>
>>Hvorfor det?
>>Jeg har svært ved at forstå hvorfor noget der virker og kører stabilt
>>skal opgraderes.
>
> Sikkerheds-patches?
>
> Lidt afhængig af det givne scenarie kan man måske argumentere
> for, at det ikke betyder så meget.

Remote exploits i kernen er sjældne, lokale kommer an på hvad man
har af brugere.

> En anden detalje er, at jo længere systemer kører, desto større
> er risikoen for, at det er svært at få dem op at køre, når de
> endelig har været nede at vende.

Kun hvis der er nogen der piller.

Vi har haft linux-maskiner stående som routere, printservere m.m.
der har haft oppetider på over 400 dage (og det var dengang
tælleren startede forfra ved 497 dage).

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>> Lidt afhængig af det givne scenarie kan man måske argumentere
>> for, at det ikke betyder så meget.

>Remote exploits i kernen er sjældne, lokale kommer an på hvad man
>har af brugere.

Derfor "lidt afhængig af scenarie". Hvis hele firmaet har lokale
konti, hvordan ser det så ud? Er ledelsen 100% sikker på, at der
absolut ikke er nogen brådne kar mellem? Og så videre...

>> En anden detalje er, at jo længere systemer kører, desto større
>> er risikoen for, at det er svært at få dem op at køre, når de
>> endelig har været nede at vende.

>Kun hvis der er nogen der piller.

Derfor "lidt afhængig af scenarie".

Men det lyder ret uprofessionelt at basere sin drift på, at der
ikke er nogen, der piller.

Mvh.
   Klaus.

---

Den Mon, 2 Apr 2007 19:35:15 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> Lidt afhængig af det givne scenarie kan man måske argumentere
>>> for, at det ikke betyder så meget.
>
>>Remote exploits i kernen er sjældne, lokale kommer an på hvad man
>>har af brugere.
>
> Derfor "lidt afhængig af scenarie". Hvis hele firmaet har lokale
> konti, hvordan ser det så ud?

Det kommer an på firmaet.

> Er ledelsen 100% sikker på, at der
> absolut ikke er nogen brådne kar mellem? Og så videre...

Bare man stoler på sine ansatte. Jeg har set situationer hvor man har
haft mode 666 på alle vigtige datafiler (og 777 på de tilhørende
mapper). Når man stoler så meget på sine ansatte, er lokale exploits
irrelevante.

>>> En anden detalje er, at jo længere systemer kører, desto større
>>> er risikoen for, at det er svært at få dem op at køre, når de
>>> endelig har været nede at vende.
>
>>Kun hvis der er nogen der piller.
>
> Derfor "lidt afhængig af scenarie".
>
> Men det lyder ret uprofessionelt at basere sin drift på, at der
> ikke er nogen, der piller.

Hvorfor skulle man pille ved en komplet uinteressant server (fx en
printserver) der bare virker?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>> Derfor "lidt afhængig af scenarie". Hvis hele firmaet har lokale
>> konti, hvordan ser det så ud?

>Det kommer an på firmaet.

Hence, "lidt afhængig af scenarie".

>> Men det lyder ret uprofessionelt at basere sin drift på, at der
>> ikke er nogen, der piller.

>Hvorfor skulle man pille ved en komplet uinteressant server (fx en
>printserver) der bare virker?

Ny printer?

Mvh.
   Klaus.

---

Den Mon, 2 Apr 2007 19:55:55 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> Derfor "lidt afhængig af scenarie". Hvis hele firmaet har lokale
>>> konti, hvordan ser det så ud?
>
>>Det kommer an på firmaet.
>
> Hence, "lidt afhængig af scenarie".
>
>>> Men det lyder ret uprofessionelt at basere sin drift på, at der
>>> ikke er nogen, der piller.
>
>>Hvorfor skulle man pille ved en komplet uinteressant server (fx en
>>printserver) der bare virker?
>
> Ny printer?

Det skulle forhåbentlig ikke påvirke boot.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>Det skulle forhåbentlig ikke påvirke boot.

Allerede når man bruger ordet "forhåbentlig", er ændringen jo
forbundet med en risiko. Om det er et reelt problem, afhænger
af de konkrete omstændigheder.

Mvh.
   Klaus.

---

Klaus Ellegaard skrev:

> Leonard <piper28a@gmail.com> writes:
>
>>Hvorfor det?
>>Jeg har svært ved at forstå hvorfor noget der virker og kører stabilt
>>skal opgraderes.
>
> Sikkerheds-patches?


Det er umindelige tider siden, at der har været grund til at patche min
backup- og printserver. Det er en gammel bærbar med Linux, som vist stadig
kan køre en times tid på batteriet, så det er kun ved lidt større
strømsvigt at den rebooter. Den har da været oppe over et år et par gange.

> Lidt afhængig af det givne scenarie kan man måske argumentere
> for, at det ikke betyder så meget.
>
> En anden detalje er, at jo længere systemer kører, desto større
> er risikoen for, at det er svært at få dem op at køre, når de
> endelig har været nede at vende.
>
> Udfordringen dér er, at detaljer som /etc/fstab ikke er blevet
> opdateret, men filsystemer bare er mounted i hånden ("den går
> alligevel aldrig ned").

De kan man jo lade være med. Og jeg ændrer jo alligevel kun på den slags
når jeg skifter diske og så booter jeg.

Det kan godt være at det efter en større ændring kan være smart at reboote
for at se om man fik det hele gjort permanent og opdage problemer, mens man
stadig kan huske hvad man gjorde. Men derefter kan en Linux-maskine godt
passe sig selv i lang tid.

> Jo længere sådan en maskine kører, desto flere af den slags
> småproblemer risikerer der at opstå. Når skidtet så endelig
> skal genstartes klokken 3 en morgen, er der måske 30 af den
> slags problemer.

Det eneste af den slags, jeg har været ude for, var en Sun workstation, der
ikke ville starte efter en reboot før jeg løftede den og rystede den.

--
Niels