=== Guest60014 is now known as slystone === br34l_ is now known as br34l [09:31] hey. wie kann man herausfinden wieso das tmpfs unter /run 100% belegt und welche prozesse dafür verantwortlich sind? wenn ich mit "du" schaue, sehe ich nur dateien, die wesentlich kleiner sind und insgesamt vielleicht 200mb belegen [09:35] deem: wie groß ist dein /run denn? [09:36] 6,3G [09:38] Oha. [09:38] Das ist ja schon ein deutlicher Unterschied. [09:38] sind halt 10% vom ram :) [09:38] Jo [09:41] ich würde da ja irgendnen nicht ganz offensichtlichen effekt bei der grössenberechnung im tmpfs vermuten [09:41] theoretisch sollte der doch swappen, wenn /run voll ist, oder nicht? [09:41] jo [09:42] in meinem fall tut er das aber nicht und wenn ich versuche einen neuen docker container zu starten, bricht das ab, weil das tmpfs voll ist... [09:42] Läuft das System ordentlich? Vielleicht ist es tatsächlich nur ein Anzeigebug [09:42] ok [09:42] das hab ich auf ganz vielen systemen. 10 von 16 haben das problem [09:43] laufen alle auf 14.04 [09:43] nein, ich glaub da eigentlihc nicht an nen bug. mehr, dass irgendetwas einfach kontraintuitiv berechnet wird. [09:43] und dann schlage quotas zu mit denen man vorher nicht gerechnet hat. [09:43] ich vermute da ja ein bisschen ein problem mit dem cadvisor [09:55] kann man denn /run irgendwie aufräumen oder muss man die nodes dafür rebooten? [10:35] wenn da noch Prozesse File-Deskriptoren offen haben zu Dateien, die wieder gelöscht sind, können sie die Dateien weiternutzen, man sieht sie aber nicht im ls, der Speicherplatz ist natürlich trotzdem belegt [10:42] deem: ^^ und mit lsof +L1 kannst du dir auch die bereits gelöschten aber noch offenen Dateien anzeigen lassen [10:52] geser: interessant! [10:57] tach [11:17] geser: schau ich direkt mal nach. danke dir [11:20] da war tatsächlich atop dran schuld [11:20] das hatte ne datei atop.acct offen mit 6,3G [11:24] über atop als resourcehog bin ich auch schon mal gefallen... wenn dann nmon :) [11:24] das hat der managed dienstleister da installiert. in version 2.2 ist das auch fexied, aber das gibt es in 14.04 leider nicht [11:24] fixed* [11:30] seltsam... auf einigen nodes hat /run immernoch 100%, aber es sind keine großen dateien mehr drin... [11:34] k1l_: danke für gestern. das problem ist gelöst :) [11:34] :) [12:52] hi, frage zu raid unter linux. denke mal es ist ratsamer ein raid0 mit dmrad aufzusetzen. performanceunterschiede zu einem fakeraid mit intel onbard lösung dürfte sicher nicht existent sein ... oder irre ich mich? [12:53] und was ich auch gerne wüsste, gehen die platten auch bei dmraid dann in den standby? [12:55] gut möglich, dass es da unterschiede gibt. aber wozu überhaupt raid0? [12:55] du meinst mdadm? [12:55] koegs: ja, mdadm [12:55] raid0 einfach weil ich den platz der beiden platten haben will, datensicherheit spielt keine rolle [12:56] ich glaub bei modernen CPUs ist der overhead vernachlässigbar, hab aber keine erfahrungswerte dazu [12:56] fakeraid setzt im übrigen ja auch auf die CPU [12:57] koegs: ist mir bekannt, läuft auf dem dektop bereits, aber nur weil das windows im dual boot das raid sonst nicht erkennen würde [12:57] da würd ich ja eher jbod, lvm, zfs oder sowas machen [12:57] zfs mit ssd cache soll auch toll sein :) [12:59] ppq: auch wenn softraid, performace bei r/w ist doch höher als lvm mit beiden platten. und system läuft bereits komplett auf SSD, geht rein um ein datengrab was ab und an mal mehr I/O Performance braucht [12:59] Wichtige Daten liegen dabei eh auf einem RAID5 MIT backup, RAID != backup ist durchaus bekannt =) [12:59] jojo, alles gut :) [13:00] dann wäre nur interessant zu wissen ob die platten noch in standby gehen, wenn sich nix tut ... zu 90% idlen die nämlich [13:01] aber denke mal bleibt dann doch nur das testen [13:01] hdparm kann das doch sicher einstellen [13:02] die WD Yellow ignorieren leider die settings vie hdparm ... hd-idle hab ich zwar installiert, aber der macht das auch eher schlecht als zuverlässig [13:02] hdparm -> /dev/sdb klappt einwandfrei, platte geht in den standby. auch hörbar ... hdparm -C /dev/sdb zeit danach auch standby statt active/idle [13:03] hdparm -Y - sorry [13:27] scheint als würde hdparm -S funktionieren ... 180 für 15min hatte jedenfalls gerade erfolg [13:45] bei mdadm raid wird es wohl sinnvoller sein in der hdparm.conf /dev/disk-by-id/blafoo einzutragen [14:50] hatte mit mdadm ein raid0 erstellt, soweit auch gut und lässt sich händisch auch problemlos mounten. trage ich das device jetzt mit uuid in die fstab will er das nicht mounten [14:51] welche uuid hast du da eingetragen? [14:52] die ich über blkid für md0p1 bekommen habe [14:52] und was bedeutet "will er das nicht mounten"? [14:52] bekomme ein timout beim mounten [14:53] sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf wurde auch gemacht [14:57] blkid gibt dir in den Fall nicht die UUID des Dateisystems.http://unix.stackexchange.com/questions/129497/difference-between-uuid-from-blkid-and-mdadm [14:57] Title: linux - Difference between UUID from blkid and mdadm? - Unix & Linux Stack Exchange (at unix.stackexchange.com) [14:57] sdx23: also doch besser via /dev/md0 /mnt/md0 mounten [14:57] ? [14:58] nein, finde die UUID vom Dateisystem, was du daraufgemacht hast. [14:59] Wenn das ein GPT Partitionstabelle ist, gibt's auch PARTUUID [15:00] scheint als würde mdadm beim booten das device garnicht erst erstellen [15:02] mdadmin --detail --scan zeigt jedenfalls md0 als inactive [15:02] ah, ich dachte du machst mount -a - sag das doch. Sonst haette ich gleich danach gefragt. [15:04] nein, bin aber gerade auf der notfall shell, da will auch ein mount -a nicht, da das raid device noch inactive ist [15:11] sdx sehe gerade, er sagt nur noch von einer der beiden platten, sie sei linux_raid_member, nach dem erstellen via mdadm --create waren noch beide platten raid member [15:13] vor dem reboot waren das noch sdb und sdc, nach dem reboot jetzt sdb und sde, wobei sde nicht mehr raid member sein soll [15:23] wie ich das sehe wurde tatsächlich die alte partition von /sdc wiederhergestellt, statt es als raid_member zu belassen [15:24] ich vesteh nur nich warum [15:44] jetzt geht es, er hat sich wohl am GPT format von sdc aufgehangen. nach mklabel msdos und neuerstellen des raid0 hat er es nun gefressen und überlebt auch ein reboot [15:45] ist bekannt ob mdadm mit gpt nicht zurechtkommt? [20:58] servus :-) [21:00] ich habe mal eine kurze frage, ich habe einen neuen kleinen Ubuntu 16.04 server auf dem ich einen MySQL server installiert habe, nun versuche ich mich von zuhause aus über workbench zu connecten, bekomme aber immer die meldung das ich mich nicht connecten darf, obwohl ich das bind = 0.0.0.0 schon gesetzt habbe oder liegt das daran das ich root dafür nicht verwenden darf? [21:03] remote root login ist immer erstmal eine kack idee [21:04] schon klar [21:05] wollte eigentlich damit nur erstmel einen neuen user anlegen und root deaktivieren [21:15] aber mal nebenbei, habe in zwischen über die konsole einen neuen benutzer angelegt und darf mich trotzdem nicht conncten :-) [21:21] okay habs hinbekommen :-) [21:21] also nicht für root sondern für meinen neuen user [21:21] Soll ich die lösung mal posten oder passt das hier eher nicht? [21:23] wenn die Frage hier hier schon gestellt wurde kann die Lösung schon auch noch dahinter (passend oder nicht *find*) [21:25] https://paste.ubuntu.com/23969280/ [21:25] Title: Ubuntu Pastebin (at paste.ubuntu.com) [21:26] dann klapt auch der zugriff über workbench [21:29] OUCH [21:29] Das ist so ziemlich die schlechteste Lösung. [21:30] Leg den Benutzer einfach korrekt an (user@hostname) und gib ihm Rechte auf eine Datenbank. Alles andere macht man dann als root, ohne GUI. Und der User hat Bunt mit Maus. [22:02] bekks: ok ... [22:02] hmmm.... [22:03] bekks: was sollte ich dem benutzer jetzt wieder wegnehmen damit es passt ? [22:09] das "grant all privileges on *.*" wegnehmen und ersetzen durch "grant all privileges on spezifischedatenbank.*" [22:10] außerdem die rechtre für "monty'@'%" droppen, nur localhost reicht, mach dann nen ssh-tunnel zu dem server (wenn der im internet steht) [22:11] https://dev.mysql.com/doc/workbench/en/wb-mysql-connections-methods-ssh.html [22:11] Title: MySQL :: MySQL Workbench Manual :: 5.3.3 Standard TCP/IP over SSH Connection Method (at dev.mysql.com) [22:13] aber nicht mit dem root system- (ssh-) benutzer authentifizieren sondern mit nem eingeschränkten system-user-account. der muss nix können außer ne tcp-verbindung durchschleifen [22:13] und ssh-authentikfizierung per key, nicht per passwort. [22:13] MultiStorm: ^ [22:14] tomreyn: ok, wird so gemacht :-) [22:15] yeay, und wieder das internet ein ganz klein wenig weniger unsicher gemacht [22:16] naja erstmal muss ich das so hinbekommen :-)+ [22:18] kannst ja nochmal fragen wenn was nicht hinhaut [22:18] glaube mir das werde ich aber ich weiss nicht wie weit ich heute noch komme, ist schon spät [22:22] tomreyn: dan könnte ich auch das bild = 127.0.0.1 wieder reinnhemen oder? [22:22] bild = bind [22:32] tomreyn: also connect über SSH und Workbech funktioniert schonmal tadellos [22:33] jetzt muss ich nur nooch rausfinden wie ich die rechte für den user droppe :-)7 [22:39] tomreyn: auch erledigt, ich danke dir, jetzt hast du das Internet wirklich ein klein wenig sicherer gemacht