Root Speicher versehentlich gefüllt, wie löschen? Ausserdem kein HDD Ruhezustand mehr

[Dennis086]

Hallo zusammen und ein Frohes neues Jahr.

ich hoffe bei einem von mehreren Problem was ich gerade mit meiner DS216j aktuell habe auf eure Hilfe.

1) Wie oben beschrieben habe ich versehentlich mit dem Jdownloader Daten auf das Root verzeichnis der DS kopiert. Downloadpfad statt auf
Jetzt habe ich das Problem das nichtmal mehr Updates funktionieren da die Kapazität nicht mehr ausreicht.

Wie kann ich (möglichst einfach) das Root verzeichnis löschen ohne wichtige Daten zu gefährden?

2) Leider funktioniert ausserdem der HDD Ruhezustand auch nicht mehr nachdem ich die DS komplett neu aufsetzen musste. (Nach Einbau einer zweiten HDD versehentlich Raid 1 erstellt)
Um zu vermeiden das ein Gerät die DS weckt hab ich das LAN Kabel gezogen allerdings gingen die HDD's trotzdem nicht in Hibernation.
Aus Verdacht und anderen Beschreibungen hab ich anschließend Jdownloader deaktiviert aber geholfen hat es leider auch nicht..

Vielen dank schonmal im vorraus für eure Hilfe.

 

[dil88]

Zu 1. Falls Du ssh (oder telnet) im DSM aktiviert hast, kannst Du per ssh eine Shell aufmachen (unter Windows z.B. mit dem Tool putty), dort dann mit dem Befehl

sudo -i

Superuser root werden (gleiches Passwort wie der DSM-Admin-User) und nach den jdownloader Dateien suchen (Downloads oder Logfiles). Hast Du sie gefunden, kannst Du sie mit dem rm-Kommando löschen.

 

[Dennis086]

Ich Poste hier mal den bisherigen verlauf:
root@Server:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 1.9G 307M 87% /
none 249M 0 249M 0% /dev
/tmp 250M 1.2M 249M 1% /tmp
/run 250M 2.5M 248M 1% /run
/dev/shm 250M 4.0K 250M 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
/dev/vg1001/lv 5.5T 2.3T 3.2T 42% /volume2
/dev/vg1000/lv 3.6T 500G 3.1T 14% /volume1
root@Server:~# cd /dev/md0
-ash: cd: /dev/md0: Not a directory
root@Server:~# dev/md0
-ash: dev/md0: No such file or directory
root@Server:~# /dev/md0
-ash: /dev/md0: Permission denied
root@Server:~#

Kann ich sonst den kompletten /dev/md0 löschen oder mit welchen Befehlen gehe ich in den Ordner und lasse mir Daten anzeigen?

 

[dil88]

Nein, Du solltest mit dem Kenntnisstand, den Du hast, auf keinen Fall ungeprüft irgendetwas löschen. Es geht hier nicht um /dev/md0 sondern um das Rootfilesystem /, das Du ganz hinten am Ende der Zeile findest. Da ist das DSM drauf, das solltest Du ganz sicher nicht löschen.

Du musst schon weiter suchen und dafür mit folgendem starten:

du -xhd 1 /

Wenn Du die Suchfunktion des Forums nutzt, findest Du weitere Informationen zu dem Thema.

Edit: Wie man Verzeichnisse wechselt (cd für change directory) und ihren Inhalt ausgeben läßt (ls für list), findest Du im Wiki.

 

[Dennis086]

Scheinbar hat Jdownloader ein neues Verzeichnis "Downloads" im Root angelegt.
root@Server:~# ls
Downloads

Bei deinem Befehl kam das:
root@Server:~# du -xhd 1 /
16K /volumeUSB1
32K /.old_patch_info
8.6M /etc
4.0K /initrd
1.0G /root
81M /var
4.0K /mnt
7.5M /etc.defaults
770M /usr
8.9M /.syno
5.9M /var.defaults
4.0K /lost+found
4.0K /tmpRoot
16K /.system_info
1.9G /

 

[dil88]

Das ist wohl auch das (Haupt-)Problem. Löschen kannst Du es mit:

rm -rf /root/Downloads

Du solltest aber vorher jdownloader deinstallieren oder umkonfigurieren.

 

[Dennis086]

Vielen Dank! Hat funktioniert.
Siehe hier:
root@Server:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 885M 1.3G 40% /
none 249M 0 249M 0% /dev
/tmp 250M 1.2M 249M 1% /tmp
/run 250M 2.5M 248M 1% /run
/dev/shm 250M 4.0K 250M 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
/dev/vg1001/lv 5.5T 2.3T 3.2T 42% /volume2
/dev/vg1000/lv 3.6T 500G 3.1T 14% /volume1

Unter ls wird jetzt auch nichtsmehr angezeigt:
root@Server:~# ls
root@Server:~#

Jdownloader war bereits umkonfiguriert gewesen nachdem ich meinen Fehler bemerkt hatte.
Wieso meinst du (Haupt)problem? Sonst hab ich eigentlich noch nie was in Root gespeichert ?

 

[dil88]

Weil es auch noch eine Logdatei unter /var/log geben könnte. Schau 'mal per

ls -l /var/log

 

[PsychoHH]

Und diese wird auch sehr gerne von JDownloader zugemüllt.
Infos gibt es im Hauptthread

 

[Dennis086]

Bei der Logsuche kam das heraus:

root@Server:~# ls -l /var/log
total 33084
-rw-rw---- 1 system log 50950 Jan 2 21:10 apparmor.log
-rw-rw---- 1 system log 148774 Jan 2 21:11 appindex.log
-rw-rw---- 1 system log 1472 Jan 2 21:07 audio_debug_msg
-rw-r----- 1 root log 814093 Jan 4 12:20 auth.log
-rw-rw---- 1 system log 30563 Jan 2 20:57 bash_err.log
-rw-rw---- 1 system log 9606 Jan 4 12:20 bash_history.log
-rw-rw---- 1 system log 5125 Jan 2 21:09 datascrubbing.log
-rw-r--r-- 1 root root 7478 Jan 1 17:47 DeviceBusyList
-rw-r--r-- 1 root root 54568 Jan 3 10:35 disk_health_information.json
-rw-rw---- 1 system log 387392 Jan 2 21:10 disk.log
-rw-r--r-- 1 root root 0 Dec 28 2016 disk_log.xml
-rw-r--r-- 1 root root 1643 Jan 2 21:10 disk_overview.xml
drwxr-xr-x 2 root root 4096 Jan 3 12:43 diskprediction
-rw-rw-rw- 1 root root 2247 May 28 2018 disk_smart_test_log.xml
-rw-r--r-- 1 root root 600898 Jan 2 21:10 dmesg
-rw-r--r-- 1 root root 47960 Jan 19 2018 dmesg.1.xz
-rw-r--r-- 1 root root 567 Dec 28 15:32 dms.log
-rw-r--r-- 1 root root 158099 Jan 2 21:07 dpkg.log
-rw-r--r-- 1 root root 109667 Jan 2 21:07 dpkg_upgrade.log
-rw-rw---- 1 system log 1169221 Jan 2 21:10 esynoscheduler.log
-rw-rw---- 1 system log 2629988 Jan 2 21:10 fileindexd.log
-rw-rw---- 1 system log 67428 May 9 2018 fileindexd.log.1.xz
-rw-rw---- 1 system log 51404 May 4 2018 fileindexd.log.2.xz
-rw-rw---- 1 system log 59628 Mar 11 2018 fileindexd.log.3.xz
-rw-rw---- 1 system log 76364 Feb 12 2018 fileindexd.log.4.xz
drwxr-xr-x 2 root root 4096 Feb 5 2018 fsck
-rw-rw---- 1 system log 3846 Sep 8 2017 ha.log
drwxr-xr-x 2 root root 4096 Feb 13 2017 healthtest
-rw-rw---- 1 system log 589023 Jan 2 21:10 iscsi.log
-rw-r--r-- 1 root root 5483169 Jan 4 12:11 JDownloader.log
-rw-rw---- 1 system log 1159812 Jan 2 21:09 kern.log
drwxr-xr-x 2 admin users 4096 Jun 19 2017 lighttpd
-rw-rw---- 1 system log 6020569 Jan 3 09:20 messages
drwxr-x--- 2 http root 4096 Dec 28 2016 nginx
-rw-rw---- 1 system log 16103 Jun 21 2017 php56-fpm.log
-rw-rw---- 1 system log 218055 Jan 2 21:10 postgresql.log
-rw-rw---- 1 system log 298258 Jan 4 12:15 router.log
drwxr-xr-x 2 root root 4096 Dec 28 2016 samba
-rw-rw---- 1 system log 1383134 Jan 2 21:10 scemd.log
drwxr-x--- 2 root root 4096 Oct 10 18:36 selfcheck
-rw-rw---- 1 system log 4610 Dec 27 13:35 sfdisk.log
-rw-r--r-- 1 root root 140 Jan 2 13:07 smart_extend_log
-rw-r--r-- 1 root root 140 Dec 28 00:02 smart_quick_log
drwxr-xr-x 2 root root 4096 Dec 31 01:24 smart_result
-rw-rw-rw- 1 root root 21975 Jan 2 21:09 space_operation_error.log
-rw-r--r-- 1 root root 12899 Jan 2 21:10 synocmsclient.log
-rw-rw---- 1 system log 3846245 Jan 2 21:10 synocontentextractd.log
-rw-rw---- 1 system log 57388 Sep 8 2017 synocontentextractd.log.1.xz
-rw-rw---- 1 system log 44952 Feb 15 2017 synocontentextractd.log.2.xz
-rw-rw---- 1 system log 37388 Jan 28 2017 synocontentextractd.log.3.xz
-rw-rw---- 1 system log 52928 Jan 27 2017 synocontentextractd.log.4.xz
-rw-rw---- 1 system log 6844 Feb 22 2017 synocontentsearchd.log
-rw-r--r-- 1 root root 979326 Jan 4 11:16 synocrond-execute.log
-rw-rw---- 1 system log 214986 Jan 2 21:10 synocrond.log
-rw-rw---- 1 system log 940008 Jan 2 21:18 synoelasticd.log
-rw-rw---- 1 system log 80504 Oct 26 19:53 synoelasticd.log.1.xz
-rw-rw---- 1 system log 162144 Feb 10 2018 synoelasticd.log.2.xz
-rw-rw---- 1 system log 400148 Oct 5 2017 synoelasticd.log.3.xz
-rw-rw---- 1 system log 68284 Jul 30 2017 synoelasticd.log.4.xz
-rw-rw---- 1 system log 172935 Jan 2 21:07 synofeasibilitycheck.log
-rw-rw---- 1 system log 1788955 Dec 29 03:03 synoindex.log
-rw-r--r-- 1 root root 8210 Nov 18 2017 synoinfo.conf.bad
drwxr-x--- 2 system log 4096 Jan 4 12:19 synolog
-rw-r--r-- 1 root root 2497102 Jan 2 21:11 synopkg.log
-rw-rw---- 1 system log 22800 Jan 2 21:07 synopoweroff.log
-rw------- 1 root root 73117 Jan 2 21:10 synorelayd.log
-rw-rw---- 1 system log 1398 Jan 1 17:05 synoscheduler.log
-rw-rw---- 1 system log 221718 Jan 4 12:15 synoservice.log
-rw-rw---- 1 system log 115952 Dec 25 16:31 synoservice.log.1.xz
-rw-rw---- 1 system log 4469 Jan 2 21:07 synotifyd.log
-rw-r--r-- 1 root root 13981 Jan 2 21:07 synoupdate.log
-rw-rw---- 1 system log 67389 Jan 2 21:09 syslog.log
-rw-rw---- 1 system log 6244 Jan 2 21:00 sysnotify.log
drwxr-xr-x 2 root root 4096 Jan 2 19:59 upstart

Ist da jetzt etwas dabei was "besonders schlimm" ist? Wenn nicht würde ich gerne vermeiden da noch groß mehr drin rumzuwerkeln da ihr ja schon ganz richtig bemerkt hab das ich wenig Ahnung in dem Bereich habe.

 

[dil88]

Schlimm sowieso nicht, besonders voll ist das Verzeichnis nicht. Aber die Datei JDownloader.log ist bei anderen Leuten schon zum Problem geworden. Deswegen würde ich JDownloader so konfigurieren, dass dieses Logfile auf einem Volume landet, und würde es dann hier wegmoven oder löschen.

 

[Dennis086]

Auf der Weboberfläche von JD hab ich sogut wie keine Einstellungen zum Log Speicherort gefunden. Wie lässt sich das konfigurieren?
Wegmoven oder löschen wäre ja einfach aber JD erstellt ohne Konfig bestimmt immer wieder eine neue Log Datei im Root.

 

[synfor]

Suche in den Profieinstellungen nach Log.maxlogfilesize.

 

[Dennis086]

Suche in den Profieinstellungen nach Log.maxlogfilesize.

Hab's gefunden. Vielen Dank!
Stand auf 10485760. Habs umgestellt auf 0 da mich der JD Log überhaupt nicht interessiert und ich auch vermutlich nie dazu kommen werde darin etwas nachzuschauen.
Damit wäre das Problem nun endlich behoben und gesichert das ich keine Probleme mit zu großen Logs von JD bekomme. Vom Googeln hat man da ja schon fast Angst bekommen, (nicht mehr startende DS usw.)

Hat das Problem das die HDD's nicht mehr in den Ruhezustand gehen evtl mit Java8 zutun?
Ich weiß das ist ein leidiges und oft beschriebenes Problem allerdings fande ich die Funktion wirklich gut da meine DS teilweise lange nicht läuft.
Ruhezustand soll nach 3 Std. erfolgen.
BIsher ausprobiert habe ich folgendes:
- https://www.synology.com/de-de/knowledgebase/DSM/help/DSM/AdminCenter/system_hardware_hibernation "abgearbeitet"
- LAN Kabel eine Nacht lang abgesteckt
-JD im Paketzentrum deaktiviert.

Habt ihr evtl noch eine Idee an welcher Einstellung es liegt?