Nohup komplettering: Överbliven Sygate NAS transformerad till dedikerad sever för att spara ner från internet

2015-07-22

Det visade sig att sidan jag länkade till i Överbliven Sygate NAS transformerad till dedikerad sever för att spara ner från internet för att skapa proceser som inte dör så lätt (primärt här så jag kan logga av planerat eller oplanerat utan att de dör) så jag slipper försöka göra processer av dem inte gav något uppenbart användbart (här finns den) för användningen här (dels mycket rörande X som jag knappast lär starta upp resp. lösningar inkluderande kompilerande kommandon jag inte hört talas om innan som jag direkt minns).


Emellertid fungerade nohup (det visade sig att nohup är POSIX snarare än gammalt System V kommando eller liknande) och presterade helt ok:



Vidare som default att se i bilden ovan till vänster (till höger filen där resultaten av wget sparas) skrivs vad som annars hade hamnat på standard-out ner i fil vilket bl.a. bör lösa de problem relaterade att logga ut från ssh Wikipedia refererar till i Nohup - Overcoming hanging.


Och det hela klarade oplanerad forced log out utan problem när Puppy-installationen jag anslöt från (min internet-dator) av någon anledning tappade sin DHCP-adress (antagligen något jag av och till råkar komma åt i planelen när fokus flyttas efter att kommit åt mus-lösningen jag använder) när klienten jag ansluter från ty idag har det hänt några gånger och det är absolut inte NAS-enheten som stör enheterna framför det lokala nätet då dom orkar mycket av samma orsaker uttryckta i diskussionen rörande hårdvarukrav i vill jag mena och kan väl argumenterats någon gång - en 20 år sedan - kunnat något lite om det i alla fall).


D.v.s. jag är tämligen nöjd så här långt eftersom ännu verkar helt sluppit ifrån att behöva ens kompilera ner något nytt till NAS-enheten och än mindre behövt uppdatera eller byta ut OS.


Istället för cron


Mer eller mindre hårdvara

Rörande hårdvarukrav gäller ju förövrigt att inte riktigt samma enkla samband gäller när det kommer till lösningarna för att ge andra enheter i nätverket tillgång till nätverks-kataloger (SAMBA o.s.v.). Lätt spekulativt eftersom det aldrig blev av att sätta upp den här lösningen för seriös användning (en del läsa och skriva) kan den kanske gynnas en hel del i prestanda för allt associerat det att konfigureras om lite försiktigt.


Bl.a. tycker jag att den kanske kan gynnas av att ej spara nätet någon gång om ej specifikt ombett så utan se till att allt vi ser snabbt närmast omedelbart är konsistent medan jag tror den samtidigt vinner på att begränsa ner antalet protokoll med tillhörande processer den default har igång.


Jag har en känsla för vad man i det sista skulle välja som primär att använda för ej låg-last access kanske bäst är vad man gör över någon lämplig liten introduktion kring och ser om det kan konfigureras bättre för sådan användning.


Spekulativt är väl ingenting bättre eller sämre än cirka SAMBA jag generellt oavsett när, var och hur har en känsla av hör till sådant som kom till världen för evigheter sedan och som numera på ett antal år inte överdrivet förbättras i någon implementation av det. Och utan tvekan långsammare en handskrivna smala legacy-lösningar man gör själv: Jag ser dock som ingen omedel rationell orsak till varför det skulle vara så? Men så har jag aldrig haft ambitionen att lära mig SAMBA heller.