Synology-Forum.nl
Firmware => Synology DSM algemeen => Topic gestart door: Chris12 op 22 maart 2020, 10:48:29
-
Hallo,
Ik zag vandaag toen in de DS415+ wilde gaan updaten de volgende melding staan:
" Insufficient capacity for update. Please contact Synology Support for assistance"
Na wat googlen vond ik meer mensen met dit issue, maar ik kom er eigenlijk niet verder anders dan dat ik zie dat het ligt aan:
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 1.8G 390M 83% /
Ik kan inloggen met putty als root om verder te kijken:
root#/usr/bin/du -d 1 -xh /
6.9M /var.defaults
8.3M /etc.defaults
4.0K /mnt
9.5M /etc
36K /.old_patch_info
20M /.syno
910M /usr
192M /var
4.0K /initrd
4.0K /tmpRoot
674M /root
20K /.system_info
4.0K /lost+found
1.8G /
Maar hier houd het dan eigenlijk op. Wat kan ik nu verder onderzoeken waardoor het komt?
-
In /usr en in /root staan beide wel erg veel files.
Bij mijn 415+ is het:
$ sudo /usr/bin/du -d 1 -xh /
Password:
16K /opt
20K /.system_info
432M /var
14M /etc
100K /root
36K /.old_patch_info
20M /.syno
1.1G /usr
6.9M /var.defaults
4.0K /lost+found
8.3M /etc.defaults
4.0K /initrd
4.0K /tmpRoot
16K /volumeUSB1
4.0K /mnt
1.5G /
Edit: Ik zie dat mijn /usr nog groter is. KIjk dus naar de tip van Birdy hierna.
-
674M /root
/root is de home map van gebruiker root.
Er is 674M aan data aanwezig, wat niet normaal is.
Het kan zijn, dat daar data in staat van een third party package.
Dus, onderzoek de map /root op herkenbare mappen/files.
-
Als ik in de root kijk staan er 100k files als deze:
-rw-r--r-- 1 root root 20 Mar 22 11:50 addstatus.jsp?sid=49205&key=30368ae9b9928e5c639a4a5078033b889776bd8e2&v2=&t=11:50&d=20200322
-rw-r--r-- 1 root root 20 Mar 22 11:55 addstatus.jsp?sid=49205&key=30368ae9b9928e5c639a4a5078033b889776bd8e2&v2=&t=11:55&d=20200322
-rw-r--r-- 1 root root 20 Mar 22 12:00 addstatus.jsp?sid=49205&key=30368ae9b9928e5c639a4a5078033b889776bd8e2&v2=&t=12:00&d=20200322
-rw-r--r-- 1 root root 20 Mar 22 12:05 addstatus.jsp?sid=49205&key=30368ae9b9928e5c639a4a5078033b889776bd8e2&v2=&t=12:05&d=20200322
-rw-r--r-- 1 root root 20 Mar 22 12:10 addstatus.jsp?sid=49205&key=30368ae9b9928e5c639a4a5078033b889776bd8ce2&v2=&t=12:10&d=20200322
-rw-r--r-- 1 root root 20 Mar 22 12:15 addstatus.jsp?sid=49205&key=30368ae9b9928e5c639a4a5078033b889776bd8e2&v2=&t=12:15&d=20200322
deze files zijn afkomstig van mn task scheduler die mn Hosola omvormer elke 5min uitleest.
Hoe kan ik al deze files in 1x verwijderen?
root:~# rm addstatus*
-ash: /bin/rm: Argument list too long
root5:~# rm addstatus.jsp*
-ash: /bin/rm: Argument list too long
root:~# rm -f addstatus.jsp*
-ash: /bin/rm: Argument list too long
-
Je probeert nu iets te verwijderen uit de home folder van root. Je zult in elk geval het goede pad moeten opgeven "/root" en ook een wildcard symbool gebruiken om alles te verwijderen.
-
ben het nu aan het proberen met:
find -maxdepth 1 -mindepth 1 -type f -name "addstatus.jsp*" -delete
kwam ik ergens anders op een linux forum tegen.
Voorlopig is het commando nog aan het runnen (aantal file is vrij groot, elke 5 min 20uur per dag, circa 3jr lang)
Inmiddels 20% meer ruimte vrij.
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 1.4G 839M 63% /
-
Gaat goed :thumbup:
Maar, je hebt het commando wel gegeven i /root zelf, mag ik hopen.
-
:thumbup:
En daarna dat script straks aanpassen zodat hij geen onnodige files wegschrijft. Of schrijf dit weg in "/tmp', dat bij elke reboot van de nas gewist wordt.
-
Inmiddels is het commando klaar, en geen oude addstatus.jsp files meer (inmiddels wel weer nieuwe).
Ook geen melding meer in DSM bij de update (DS was al up to date: DSM 6.2.2-24922 Update 4)
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 1.2G 1.1G 53% /
none 3.9G 0 3.9G 0% /dev
/tmp 3.9G 1.5M 3.9G 1% /tmp
/run 3.9G 3.2M 3.9G 1% /run
/dev/shm 3.9G 4.0K 3.9G 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
/dev/vg1000/lv 17T 7.1T 9.2T 44% /volume1
root# /usr/bin/du -d 1 -xh /
6.9M /var.defaults
8.3M /etc.defaults
4.0K /mnt
9.5M /etc
36K /.old_patch_info
20M /.syno
910M /usr
192M /var
4.0K /initrd
4.0K /tmpRoot
19M /root
20K /.system_info
4.0K /lost+found
1.2G /
Als ik het script bekijk in de taskmanager, wat moet ik dan aanpassen om die files ergens ander in weg te schrijven (of te deleten via dat script?)
today=`date '+%Y%m%d'`
minute=`date '+%H:%M'`
#get most recent webdata from Hosola / Omnik inverter
content=$(wget --user Admin --password XXXXXXXXXXXXXX@@ http://X.X.X.X/js/status.js -q -O - | sed -e 's/;/\n/g' | grep -e "^var" | grep -i webdata | sed -e 's/var webData=/,/g' | sed -e 's/"//g')
#get current power value, put all available values in array
set -- "$content"
IFS=","; declare -a Array=($*)
echo "${Array[0]}"
echo "${Array[1]}"
#post power value to pvoutput site, please change with correct SID and API key from pvoutput.org account
postdatastring="sid=49205&key=30368ae9b9928e5c639a4a5078033b889776bd8e2&v2=${Array[6]}&t=$minute&d=$today"
wget http://pvoutput.org/service/r2/addstatus.jsp?$postdatastring
-
Het script wordt gestart door 'root' dus, automatisch gaat de output naar /root
Maak een gedeelde map, b.v. Hosola
Zet bovenin het script:
cd /volume1/Hosola
Dan draait het script in feite in de gedeelde map Hosola.
Dus, dan zouden de files daarin moeten komen.
-
Of naar
cd /tmp
Of de laatste regel veranderen van
wget http://pvoutput.org/service/r2/addstatus.jsp?$postdatastring
naar
data=$(wget http://pvoutput.org/service/r2/addstatus.jsp?$postdatastring)
Dan zet je die data in een variabele i.p.v. op schijf, wat volgens mij niet nodig is want er wordt niets mee gedaan. Jij bent niet de eerste die dergelijke problemen met dit specifieke script meldt. Maar dit goed aanpakken is eigenlijk de verantwoordelijkheid van diegene die dit script gepubliceerd heeft.
-
Maar verder werken de panelen goed? Des te lager de temperatuur, des te hoger het rendement. Met de zon van vandaag maken de panelen hier overuren.
Ik heb ook een zonneboiler. Dat water is inmiddels tot boven de 80°C opgewarmd. Lekker 'gratis' douchen straks. ;)
-
Dank voor de reactie(s).
Ik heb het script nu aangepast en ik zie niet meer in de root directory de addstatus.jsp files terecht komen, maar in de /tmp directory.
Dat laatste stuk van de data in een variable zetten ipv schijf lijkt niet te werken (aangezien ik files zie in /tmp)
Hierbij het script, mocht iemand een keer dit topic tegenkomen naar aanleiding van hetzelfde issue.
(zonder herleidbare info)
#folder to temporarily store the upload data when needed
cd /tmp
#define variable day/time
today=`date '+%Y%m%d'`
minute=`date '+%H:%M'`
#get most recent webdata from Hosola / Omnik inverter
content=$(wget --user Admin --password XXXXXXX http://X.X.X.X/js/status.js -q -O - | sed -e 's/;/\n/g' | grep -e "^var" | grep -i webdata | sed -e 's/var webData=/,/g' | sed -e 's/"//g')
#get current power value, put all available values in array
set -- "$content"
IFS=","; declare -a Array=($*)
echo "${Array[0]}"
echo "${Array[1]}"
#post power value to pvoutput site, please change with correct SID and API key from pvoutput.org account
postdatastring="sid=49205&key=30368ae9b4928e5c439a4a5078033b889776bd8e2&v2=${Array[6]}&t=$minute&d=$today"
#upload collected data to pvoutput.org
data=$(wget http://pvoutput.org/service/r2/addstatus.jsp?$postdatastring)
PS. panelen werken prima (al 3jr), en leveren per jaar meer of gelijk op als ze theoretisch zouden moeten kunnen :-)
Elektra rekening is verleden tijd... nu het gas nog 8)
-
Kan je nu wel updaten ? Al gedaan ?
-
DSM was al up to date met versie DSM 6.2.2-24922 Update 4, volgens de check was er ook geen nieuwere (DS415+)
Ook manual download gaf deze versie voor de DS415+
-
Ah, dus DSM checkt kennelijk eerst of er wel een update uitgevoerd kan worden.
-
Ik heb het script nu aangepast en ik zie niet meer in de root directory de addstatus.jsp files terecht komen, maar in de /tmp directory.
Dat laatste stuk van de data in een variable zetten ipv schijf lijkt niet te werken (aangezien ik files zie in /tmp)
#folder to temporarily store the upload data when needed
cd /tmp
Zou het werken als ik in dit script direct onder de "cd /tmp" de zogenaamde clean-up regel zet met dit commando:
find -maxdepth 1 -mindepth 1 -type f -name "addstatus.jsp*" -delete
Dan wordt de voorgaande 'addstatus.jsp' regel verwijderd voordat de nieuwe wordt aangemaakt lijkt mij.
Klopt deze beredenering?
/edit/ zojuist aangepast, en dit werkt prima!
-
De cleanup is niet strikt nodig. Zeker als hij elke 5 minuten moet zoeken. Op zijn minst de zoekopdracht beperken tot de folder waar de file verwacht wordt.
Alles in /tmp wordt toch na een reboot gewist en als hij bij jou pas na 3 jaar vol gelopen is, zal er tussendoor echt wel een update voorbij gekomen zijn met een reboot.
Beter is het een folder in /tmp te maken en daar de file heen laten schrijven en die folder inclusief inhoud elke keer te wissen. (Een zoekopdracht is verspilling van cpu cycli als je weet waar alles staat)
Maar het script in dit topic uitgebreid bespreken is jammer van de tijd. Er is al een heel uitgebreid topic (https://www.synology-forum.nl/overige-software/nas-synology-taak-om-zonnepanelen-opbrengst-naar-pvoutput-te-uploaden/msg278613/#msg278613) over dat script. Iemand met problemen zal daar eerder zoeken.
En jammer dat mijn suggestie voor wget niet werkt. De functie van die wget aanroep is er alleen maar om data de uploaden. Misschien dat dit downloaden van data met een extra parameter nog te voorkomen is.
-
Ik heb hierboven een link naar dat oude topic geplaatst. En in dat topic heb ik toch maar besloten de eerste versie van het script te editten, zodat het wel veilig gebruikt kan worden.
Een beetje tegen mijn principe om andermans script te editten, maar de plaatser van het script was na april 2017 niet meer ingelogd op dit forum en laat anderen met de problemen van zijn script zitten. En de verbeteringen aan het eind van het draadje zelf, maakt de boel onoverzichtelijk omdat dit uiteindelijk tussen alle latere posts 'verdrinkt'.
-
Wel goed opgelost :thumbup: maar, ik vind het sowieso een slecht idee om eigengemaakte scripts te laten schrijven in de DSM partitie.
Laat het gewoon schrijven naar een gedeelde map (cd /volume1/Hosola), dan heb je er zicht op en kan je ermee doen wat je wilt. ;)
-
Zoals ik al schreef is dit een quick-fix. Als je een share aanmaakt gaat dat erg lastig vanuit een script. (zal vast wel kunnen met de goede systeen call) En als je een losse folder aanmaakt in volume1, moet je heel erg oppassen dat je geen naam kiest die al bestaat, want dan ga je misschien data van gebruikers wissen. Oftewel, het script wordt complexer, of er moet aanvullende uitleg komen hoe het script te gebruiken.
Er klopt wel veel meer niet aan het script. Mij gruwt het b.v. als ik scripts zie waar account gegevens en toegangsdata direct in het script staan. Als je zo'n script doorgeeft moet je er elke keer op letten dat je eerst stukken van je eigen script wegpoetst. Dat gaat een keer mis. (Zoals in het bovenstaande script ook gebeurd is met de sid en key waarden) Variabele data behoort daarom niet in een script te staan, maar in een separate file.
Ook de hele foutafhandeling mist in het script. Als de omvormer b.v. uit staat, of een storing heeft, gaat het script rustig verder en stuurt ongeïnitialiserde data weg i.p.v. een mailtje met foutmelding.