Att nautilus hänger sig på min arbetsdator (som ligger några versioner bakåt på Ubuntu) är inte ovanligt men händer inte oftare än att jag föredrar den p.g.a. sämre klick-natur än default filhanteraren för LXDE.
Idag hände emellertid något udda. De sista operativsystem jag kunde djupt var Windows 2000 Server på en av de med den samtidiga Solaris cirka. Kan man mer om Linux djupare kanske det är mer förståligt men därmed inte självklart mindre varnande rörande processhanteringen (i kontext av verkligt high-security miljö: I övrigt ligger praktiskt problematik inte i magnituder i närheten av sådant här).
Av vana när den hängde sig beordrade jag dödande av fönster från menyn som söker göra det snällare och därför generellt är att föredra. Men är ej van jag typiskt väntar på innan intierade andra åtgärder: Hinner det eventuellt (vilket för vad jag bedömer hängt ej är normalt alls då Nautilus tycks sakna vettig "tidshantering" rörande när följande upp om något signalerats till det). Denna gång hinner dock fönstret dö innan jag ens börjat göra kill (jag börjar regelmässigt högst upp och går stegvis med uppföljning med ps ner till 9). Jag följer upp med ps när det ny försvunna fönstret är borta att inga Nautilus körs då om något på annan skärm körande att jag tagit över det istället. Inga Nautilus processer är igång.
Jag startar upp ett nytt Nautilus efter död från LXDE's meny-alternativ run. Ny Nautilus fungerar normalt på alla sätt.
Några minuter senare stänger jag ner lxterminal fönster. Den Nautilus som hade hängt sig hade jag startat upp från ett av dess lxterminal istället för run i menyn. När detta lxterminal dödas - mycket märkbart p.g.a. av all status- och feltext som kastas ut i terminalen när man startar denna väg - dör min nya Nautilus.
Ska vi spekulera om orsak är vad jag kan tänka mig att kärnan cachar nyligen dödade processer och om de kan svara reattachar dem till nya. Men om så eftersom processer kunde dö på detta sätt sker det på sådant sätt att status-värden för processen återanvänds ej korrekt och därmed troligt - möjligen vid sidan om hur processen kan dödas - ej följer säkerhetsmodell för processer. Icke dokumenterade - odefinierade - vägar för att påverka processen existerar.
Det är inte första gången jag träffat på liknande icke-definierade tillstånd rörande processhanteringen i Linux. Mitt intryck är att det är jämförbart med erfarenheten av Solaris och Windows (rörande Windows när man gjorde insats ordentligt för Windows 2000 Server initialt - inkl. adderande några komponenter egentligen utanför OS samt reducerande möjlighet att aktivera delar av parallella delar av den feta kärnan vi möjligen kan referera till som "alternativa" OS inkluderade i den feta kärnan - var processhantering liksom mycket i säkerhet välfungerande medan min erfarenhet från några år bakåt nu av något Windows - ej server säkert - som kom med min laptop att dess säkerhetshantering var i mycket defunct och ej på sådant sätt att det underlättade användning: Tvärtom snarare).
Så i summering: Oavsett hur en process startas i Linux är det tänkbart att andra processer - ev. med krav att de startades av samma användare - kan definiera annars ej existerande kommunikationsvägar och möjligheter för den. D.v.s. i värsta fall ärvande rättigheter som den tidigare processen hade om de åtminstone refererar till samma fil (utan djupa kunskaper nog i Linux men från mitt intryck användande Linux definieras processens identitet från vilken fil de startats via som direkt referens d.v.s. snarare än från mjuka- och ev. hårda-fil-referenser till terminerad filnod).
Rörande korrigering av detta anar jag att en planering än mer långtgående optimering av min Linux (bl.a. planerar jag att koda om dess hantering av CPU:er för hur den lägger ut processer vilken är direkt dum utnyttjande tillgänglig processkraft brutalt dålig) kan tänkas korrigera detta. Erfarenhet från tidigare optimering jag gjort ger mig en känsla av att detta kan sortera till diverse jag råkat på i Linux ev. från början tänkt snabba upp något men som praktiskt i en stressad miljö bara orsakar problem stabilitet när pressande minne och/eller konkret ger sämre prestanda (re-attachar man processen här tror jag ex. inte för ett ögonblick att det snabbar upp något alls: Och om någon prestanda förändring kommer från det är min tro utan närmare kontroll att det bara slöar ner genom att gå utanför normalt samt riskerande diverse fel som kastas upp till kärnan att behöva hantera för att sedan börja om - Spekulativt hade jag kört min Ubuntu här "pressad" i CPU och minne under långkörning på många veckor så hade kärnan ej klarat att göra re-attach utan ev. givit flera sekunders fördröjning medan den prövar N antal gånger innan börjande om).
Jag inser att min referens inom parentes kan ge intryck av att jag kan saker om Linux. Det är emellertid falskt. Jag ser det som ett misslyckande - ett misslyckande för konceptet OS jag görande saker ovanför ej ska behöva bry mig i: Ett misslyckande för Linux - varje gång jag behöver lära något om Linux. Och ex. optimerande lär jag som jag gör det i alla fall inte ett jutta mer än jag behöver. Och pedagogiken jag använder är då inte sittande och läsa något allmänt om OS utan identifiera motsvarnade filer med logik och om jag inser logiken för vad de gör samt att det troligt är vad som är ineffektivt letande rätt på en vedertaget snabb algoritm som jag kodar in. Man lär sig verkligen inget generellt eller övergripande om Linux den vägen. Och faktiskt lär man sig ingenting nytt alls om Linux mer än vilken kod-del i filnamn - om man kommer ihåg det senare eller faktiskt inte missar att dokumentera förändringen man gör - som hanterar det man förändrat.
På den positiva sidan rörande Linux och förändringar gäller trots att det i all rimlighet inte ska vara möjligt - kan man tycka så här rent allmänt - att undvika omstart kring diverse förändringar man gör tycker man djupt. Men Linux (eller i all fall Ubuntu) är anmärkningsvärt kompetent i att klara sådant. Besläktat helt säkert men imponerande i så mycket mer är hur smidigt uppdateringar oavsett berörande program eller OS fungerar. Det är väl den tunna kärnan och allt i övrigt utspritt på enskilda komponenter som underlättar kombinerat med en idag uppenbart ruskigt fin dokumentering (eller auto-detektion) av hur olika delar beror av varandra. Möjligheter jag spekulerar hör till det mest möjliggörande för att göra det görligt för allt fler att använda Linux.
Skulle jag någonsin behöva driftsätta Linux som plattform för något liknande ett cloud hör vad jag såg här för Nautilis plus ett fåtal (två tror jag) andra småsaker jag råkat på under Ubuntu åren till vad jag skulle följa upp. Dels för att verifiera att det ej förstår säkerhetsmodell. Vidare om ej så verifiera - troligen koda om - faktiskt är meningsfullt förbättrande rörande prestanda snarare än att i sannolikhet X tidskostnad snarare ge tidsförluster över längre tid.
Sedan självklart (för mig) gäller att trots att arbetsmiljö numera aldrig får ansluta till nätet är det tänkbart på att vad vi såg här kan vara en rest-effekt av överdrivet sofistikerade modifikationer gjorda av över-drivet kunniga angripare. Visar det sig fallet är tänkbart det korrekta att tänka säkerhetsmodell utifrån att se till att kostnad föreligger för sådant. Oavsett om nu nätverkskostnad, CPU, minne m.m. som helt enkelt tar tid om övrigt falerar - eller implementerande säg en management kostnad hos ev. identifierad ansvarig organisation görande ansvariga personer synliga kanske som icke-rättrogna när det gäller kommunistpartiets koncept (snarare något annat faktiskt men funktionellt exempel: Kanske något mer Bo-liknande - Minns ni Bo-kostnaden föranledd av att man satt och trodde sig smart lyssnande på vad jag skrev i personliga anteckningar på min dator indikerande falskt över mer än ett år närmare två honom som samarbetande med demokrati-organisationer - Kanske om ni tycks indikerade här att en lagom kostnad är att göra det känt bland Bo's polare i partiet och militären: Jag tror knappast dom gillar att förklaringen vad detta snarare än allt fabrikerat).
Längre tillbaka var det ej vad jag som riktigt aktuellt men lite för mycket problem runt säg 2007 och några år framåt förändrade det bit för bit och min erfarenhet praktiskt av förändrad metodik i hantering var att det närmast binärt skar allt av det mer märkbara problemen.
Viss rest förvisso - möjligen lika gärna att de var oskyldiga men exakthet i vad man vet kring allt går inte att sätta som kräv - men där just mycket sofistikerad och därmed också mer arbetskrävande. Ansvar för sin egen historik är dessutom menar jag en moralisk rimlighet att de tar. Alternativet är ju trots allt att de accepterar vad man gjort i kontakt med mig och betalar en rimlig ersättning (310 000 svenska kronor räknat på 3 * 1250 kr per timme) tydliggörande att det ej kommer upprepas i vilket fall man kanske rörande strö-problem (ej otroligt p.g.a. av angrepp och om så ej otroligt dem) kan räkna bort dem. Så verkligen vad man valt själv och med fullmedvetenhet om det givet att jag tydliggjort det här flera gånger genom åren och de är verifierade läsare.
Mer förslappad numera och mindre praktiskt engagerad gäller dock att jag mer än kanske rimligt faktiskt här om alls kommer verifiera att det om så är externt korrumperad processhantering. Dock det troligaste är något defunct naturligt i Linux. Att understryka givet omfattande problem bakåt att man potentiellt inför ev. problem är lika sur och otrevlig som man kom att bli från det tror jag hur som helst är korrekt att göra av och till. Nya rekryteringar, äldre folk som går vidare till annat m.m. gör det sunt att påminna så man slipper mer själv-organisatoriskt-destruktivt beteende drabbande mig. Säg 75% chans.
