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.

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

Jag hade räknat med för denna NAS (Network-attached storage) att tvingas bygga om en del kanske allt på enheten. Och planerande en del för det kontrollerade jag löst möjligheter och det i sig verkade inte omöjligt. Linux variant identifierade sig utan problem:



Dessutom hittade jag enstaka exempel från personer som gjort lyckade kompileringar till den adderande in i diverse Sygate-lösningar körande systemet.


Emellertid såg jag att den hade en basal wget och prövade därför följande variant utnyttjande en omvandling av en normal lista med adresser att sampla till en stort shell script (wget varianten stödde ej -i flaggan för fil och dess perl-installation verkade också lätt begränsad och även om ej kanske problematiskt begränsad för att slippa exportsteget valde jag bort det alternativet).


echo "_URL [TAB] http://www.disastermilitarymedicine.com/manuscript//mostviewed/rss/" >> aa
echo "" >> aa
wget -U dummy_wget "http://www.disastermilitarymedicine.com/manuscript//mostviewed/rss/" -O - >> aa
echo "" >> aa
echo "___________________________________________________________________________________" >> aa
echo "" >> aa

Vilket kör utan tycks det några märkbara problem annat än att det av och till irriterar effektivitet att wget-varianten ej tillät att ställa in timeout.



Att komplettera med nästa gång

Förutom timeout kvar att lösa (ev. kompilerande en bättre wget?) ligger hela området jag vill kalla nohup. För startade jag processer som ej normalt skulle dö med skalet de startades från men det var ju 100 år sedan.


Kanske är det fortfarande nohup men sundare lämnade jag det till nästa "version" av det där jag tänker mig kontrollera lite för aktuellt OS här. Ev. även om jag gärna låter bli kanske man skulle lägga det till en tjänst som kan startas och stoppas via övergripande webb-gränssnitt till NAS-enheten.


Ev. finns nohup frågan löst i:



Slutligen vad jag direkt vet att kontrollera till närmaste modifikationen av enheten är en kontroll av hur väl den hanterar i engelskan lite mer udda tecken när de förekommer i motsvarande "html-innehåll" som sparats ner. Huuvdsakligen tänker jag på innehåll under toppdomänerna .cn och .jp.


Hur bra är NAS-enheten när det gäller kraven på hårdvara?

För ingen normal användning jag kan föreställa rörande den här typen av sampling kommer processor-kraften märkas som en begränsning för något jag har hemma. Bara för att hämta data't utan att göra någon bearbetning på enheten är kraven obefintliga.


Så länge endast ett fåtal varianter vi såg ovan körs samtidigt kan jag heller inte föreställa mig att någon som helst problematik med minne finns.


Hastighetsbestämmande med nätet är nu internet snarare än vad den klarar rörande sådant upp till.


D.v.s. huvudsakligen kommer det ner till möjlighet att lagra informationen rsp. gärna att den hanterar lagringar halv-smart i alla fall (ej välja att stänga ner sig utan att via ev. legacy-lösningar för prestanda gjort sync på filerna - Vi kan dock notera att tänkbart gjors motsvarande en sync för varje rad i script-filen): Och detta är nu vad en enhet av denna typ byggdes för att göra. Spekulativt kan några sådana här script köra upp till ett år om ej överdrivet många redundanta stora nedladdning görs utan att det självklart uppstår något problem med att lagringsutrymme börjar ta slut.


I det försiktiga startade jag upp den emellertid upp till cirka 55 000 url:er att kontrollera. Så kan processen som hämtar den push:a och starta upp nya processer utifrån indikationer om dns-fel, ev- felaktigt extrahera eller föråldrade url:er o.s.v.