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

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

• wiki.archlinux.org/index.php/Systemd/Timers

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:

• www.archlinux.org

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:

• Allow a program to continue after logoff | wiki.archlinux.org/

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.

Resultat spindling efter RSS- och ATOM-strömmar

Det huvudsakliga syftet med sista "spindla efter strömmar" (när refererat rss-ström avses vilka som helst strömmar oavsett RSS eller ATOM resp. version) projektet var att öka mängden blogg-strömmar (och på vägen dit nyhets- / pressmeddelande-strömmar) på .edu-domäner eller övrigt inriktat forskning. Spindlingen utgick från alla pressmeddelanden publicerade på EurekAlert! fortfarande i Breaking News.

Robot dumpade hittade länkar tidigt i samma fil och längre fram när jag började tråda den i filer med slumpmässigt namn. Vidare sattes ett stopp-värde per domän parametriserat vid start d.v.s. vid varje återstart eller att tråden börjar om (för att slippa hålla mycket stora mängder länkar gjorda eller att göra) är det inte självklart att de länkar först skrivna till fil för en domän tas först utan ordningen ges av filerna sorterade efter namn.

I skärmdump framgår ordningen filerna för redan besökta resp. identifierade länkar läses in. Rörande parametrisering anger första siffran antalet besök på domänen som tillåts, andra hur många länkar att besöka som tillåts ligga i minne (kan praktiskt hamna något under resp. över), tredje parametering vad som ska finnas i länken för att den ska besöka (eller tillåts resp. allt ska finnas) samt den fjärde ej i bilden omvänt från den tredje d.v.s. vad som ska uteslutas.

Utifrån tanken diskuterad i:

• Riktad sampling Blogger för ökad tillförlitlighet (och pågående unikt problematiskt internet från min accesspunkt)

Införde jag möjlighet att parametrisera vilka undermängder av identifierade länkar en tråd ska prospektera. Bl.a. lät jag trådar gå tämligen länge (kanske 10 - 48 timmar totalt) för:

• Just Blogspot.
• Wordpress.com resp. Wordpress förekommande i url.
• Typepad.com
• .edu inkl. .edu.
• .gov inkl. .gov.
• .mil inkl. .mil.
• .org inkl. .org.

En relativt övrigt kortare tid men med vid den tidpunkten startad (sista 25% av tiden robotarna vandrade nätet) snabbt expanderande i antal hittade rss-strömmar: .com (minns jag rätt ej inkl. .com.).

Samma trådar efter att de kommit igång med att besöka tidigare identifierade länkar.

Exakt som jag förväntat från när jag skapade första proof-of-concept versionen av sökmotorn gäller att spindla efter RSS-strömmar är vekt inom flera områden med viktiga newsprovidera:

• Att utgå från <link ...> levererar ej och när det leverar en försvinnande liten andel.

Istället behöver man spindla efter länkade undersidor och där suga upp länkar (jag begränsade till länkar och intrycket är att det täcker upp de flesta även om några endast skriver dem i text) till RSS-strömmar man publicerar. Detta gäller särskilt:

• Amerikanska .gov och .mil sajter.
• P.s.s. som föregående en del nyhetstidningar.

Vidare besläktat men när man väl hittar motsvarande blogg fungerar ofta <link ...>:

• Bloggar som enskilda medarbetare, organisationer m.m. har "undangömda" långt in i spindlings-väg relativt endast enklast domän-namn.

I detta spindlings-projekt sökte jag endast <link ...> medan jag vid ett föregående också analyserade länkar för att söka avgöra om de ev. är RSS. Det första projektet gav ordentligt fler RSS-strömmar men införde också diverse felaktigt antaget RSS som ännu ej filtrerats bort (bl.a. en del sitemap-länkar).

Trots att .gov och .mil prioriterades i timmar blev andelen RSS-strömmar levererade försvinnande få och inte mer än cirka 10% av vad jag lade till manuellt genom att gå igenom de viktigaste sajterna (ex. resp. vapengrens huvudsida för .mil med ex. site-sökning med Google) , tjänsterna (ex. tjänster för varningar rörande väder - ex. tsnunami-alert - o.s.v.). Det understryker hur begränsat <link ...> är.

Riktad spindling mot URL inkluderande news och/eller press levererade vettigt och tämligen högt men prioriterades relativt ordentligt mindre än övrigt. Bäst resultat i antal identifierade strömmar gavs av självklara orsaker när Blogspot, Wordpress och Typepad prioriterades. Dessa prioriterades vidare ordentligt i tid utifrån tankarna diskuterade i:

• Riktad sampling Blogger för ökad tillförlitlighet (och pågående unikt problematiskt internet från min accesspunkt)

Totalt tycks 147 172 RSS-strömmar identifierats. En del är antagligen defekta bl.a. av följande noterande orsaker:

• Angiven men används ej. D.v.s. man har växlat url någon gång men ej förändrat vad angivet alt. att den ej fungerar just när jag kontrollerat.

Den initiala start-noden EurekAlert! gav så länge jag körde en hög andel strömmar relaterade forskning. Men vilken andel det är av totalt identifierade domäner vet jag ej och har ej kontrollerat hur stort det totala antalet identifierade (spindlade eller inte) domäner är.

Trådar pollande RSS-strömmar. Den eller de parametriserade först inkl. EXTRA hämtar från vad som identifierats i diskuterad spidering. FAST särskilt prioriterade avseende bl.a. nyhetstjänster likt ex. Reuters eller New York Times (och dessutom inkluderade sådana manuellt adderade oavsett ofta uppdaterade). ALL avser en ganska stor lista skapad genom tidigare kontroll av alla sajter där det för mig är känt med ganska hög tillförlitlighet vilken entitet de tillhör (utnyttjande tvättat Wikipedia-data): totalt cirka 90 000 strömmar inkl. ett mindre antal (cirka 5000 - 20000) "defekta" strömmar och ATOM- och RSS-strömmar för samma publicering.

Sampling är e diskriminerande från annan aspekt än att det är önskvärt att en hög andel strömmar är på engelska. Och prioritet i manuellt arbete har gjorts för att söka inkludera särskilt politiska entiteter från länder "problematiska" att enkelt från domän identifiera som tillhörande ex. myndighet (ex. Sverige med government.se snarare än government.gov.se jag gärna önskat som synonym eller Japan med go.jp) liksom politiskt "mer bråkiga" länder som Ryssland och Kina. Vidare sker hantering sampling enligt principer som gör att ingen kostnad annat än i tid processing föreligger avseende att "inkludera för mycket" (undantag hantering strömmar där inlägg saknar meningsfull titel där positiv-särbehandling sker på ett antal RSS-strömmar från amerikanska myndigheter eftersom de där av och till berör varnings-tjänster vilka jag gärna vill få med just indexerade).

Spidering av url:er inkluderande news men ej .blogspot eller wordpress (därför de senare har egna trådar).

Sista raden ovanför ett antal = kan ge upp till två siffor indikerande antal länkar resp. antal strömmar identifierade.

Hur jag gärna vill se att domäner relaterat regering eller myndighet indikeras och p.s.s. relaterat utbildning med .edu..

Antal identifierade för några utvalda meningsfulla under-grupper

Totalt tycks 147 172 RSS-strömmar identifierats. Ev. summerar uppgifterna ej korrekt för undergrupperna vilket om så har att göra med logiken för hur resp. grupp tas ut när RSS-strömmarna efter spindling hämtas för att tas ned (typiskt enligt för ex. wordpress: index(lc($url),"wordpress") i Perl). Medan tillförlitlighet totalt andel är mycket god eftersom allt förekommande i filerna med identifierade RSS-strömmar tas in och lagras i hash-tabeller för att garantera unik-förekomst samtidigt som domäner som notoriskt indikerar både ATOM- och RSS-strömmar - ex. Blogspot.com - särbehandlas för att hantera detta).

Självklara blogg-plattformar

Wordpress (Oftast Wordpress.com men allt inkl. wordpress i url-feed
51190
Feedburner
1435
Blogspot (extrahering utnyttjar Google's semantik för hur strömmar namnges men ej en perfekt lösning)
46020
Typepad (inkl. typepad i url feed)
4219

Domäner indikerande meningsfull indelning verksamhet

.edu (inkl. .edu.)
4847
.gov (inkl. .gov.)
799
.org (inkl. .org.)
18179
.com (inkl. .com.)
21430
.mil (inkl. .mil.)
162

Övriga

Alla övriga (ex. ip-adresser)

3152