Opensuse 42.2 Kworker legt System lahm

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Hinweis: In dem Thema Opensuse 42.2 Kworker legt System lahm gibt es 14 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Opensuse 42.2 Kworker legt System lahm

    Tach auch,
    seit einigen Tagen legt der kworker das System alle 2 Tage lahm.
    Was habe ich geändert: 'eigentlich' nichts außer:
    1. habe versucht die saudämliche Passwort Abfragen nach dem Aufklappen des Laptops abzuschalten;
    ohne Erfolg.
    2. habe SimpleScan neu drüber installiert.

    An mehr kann ich mich nicht erinnern.

    linux-bik2:~ # uname -a

    Linux linux-bik2.site 4.4.74-18.20-default #1 SMP Fri Jun 30 19:01:19 UTC 2017 (b5079b8) x86_64 x86_64 x86_64 GNU/Linux

    Für den Inhalt des Beitrages 112544 haftet ausdrücklich der jeweilige Autor: oracle123

  • oracle123 schrieb:

    seit einigen Tagen legt der kworker das System alle 2 Tage lahm.
    Es gibt immer mehrere Kernelthreads mit dem Namen kworker. Welcher macht die Probleme? In Netz gibt es immer mal wieder Meldungen, wie Du Sie beschreibst. Häufig ist das Problem behoben mit einem down- oder upgrade des Kernel.
    Wenn Du die Suchmaschine Deines Vertrauens nutzt, findest Du u.a. dass teileweise Interrupt-Service-Routinen wie sie bspw. von Programmen-/teilen zur Einbindung von usb-devices genutzt werden, dies verursachen können. Dieses fehlerhafte Verhalten kann ggf. auch mit !würgaround!

    behoben werden. Wie Du hier lesen kannst, war ein kworker-Prozess mit einer Graka von Intel "schwer" beschäftigt - was behoben werden konnte. Mit den Infos, die Du gibst, ist wenig anzufangen.

    oracle123 schrieb:

    Was habe ich geändert: 'eigentlich' nichts außer:
    1. habe versucht die saudämliche Passwort Abfragen nach dem Aufklappen des Laptops abzuschalten;
    ohne Erfolg.
    2. habe SimpleScan neu drüber installiert.
    Natürlich kann das die Ursache sein - muss aber nicht. Was hast Du verändert (1.)? Was meinst Du mit "Passwort Abfragen" - werden mehrere Passwörter abgefragt? Warum hast "SimpleScan neu drüber installiert" - hört sich für mich nach einer Vorgehensweise an, die eher für Windows üblich ist. Mit "drüber installieren" erreicht man häufig gar nichts.
    be tolerant - not ignorant
    Alle Hunde sind schwarz.
    Es gibt einen Hund der nicht weiß ist.

    Für den Inhalt des Beitrages 112580 haftet ausdrücklich der jeweilige Autor: Boreas

  • So, hab gestern Abend noch den Kernel upgedatet. Heute nach dem Aufklappen des Laptops(Fujitsu Lifebook S, i5 8GB; KDE)
    war 136 mal der kworker aktiv; kurze Zeit später dann nur noch so um die 26 Prozesse.
    Hab einige (2) Anleitungen im Netz gefunden, die ich bei Gelegenheit ausprobieren werde und das Ergebnis dann hier poste . . .

    Mit der 'Saudämlichen' Passwortabfrage meine ich Kwallet, das immer nach dem Aufklappen das Wlan Passwort und das von root haben möchte.
    Hier versuche ich demnächst das hier'http://linux-club.de/forum/viewtopic.php?t=121297'.

    Für den Inhalt des Beitrages 112593 haftet ausdrücklich der jeweilige Autor: oracle123

  • Hier der Misthaufen; coredumpctl

    Hmm, seit heute ist auch die eth0 wech ...
    Ich sehe sie zwar in yast > netzwerkeinstellungen; kann sie dort aber nicht aktivieren oder gar löschen(wicked).


    Quellcode

    1. linux-bik2:/etc # coredumpctl
    2. TIME PID UID GID SIG PRESENT EXE
    3. Thu 2017-05-25 18:58:14 CEST 3130 0 0 11 /usr/lib/YaST2/bin/y2base
    4. Thu 2017-05-25 18:58:24 CEST 3567 1000 100 11 /usr/bin/catdoc
    5. Thu 2017-05-25 18:58:25 CEST 3569 1000 100 11 /usr/bin/catdoc
    6. Thu 2017-05-25 18:58:42 CEST 3197 0 0 11 /usr/lib/YaST2/bin/y2base
    7. Thu 2017-05-25 18:59:19 CEST 3277 0 0 11 /usr/lib/YaST2/bin/y2base
    8. Thu 2017-05-25 18:59:47 CEST 3375 0 0 11 /usr/lib/YaST2/bin/y2base
    9. Thu 2017-05-25 19:10:39 CEST 4663 1000 100 11 /usr/bin/catdoc
    10. Thu 2017-05-25 19:13:16 CEST 4826 1000 100 11 /usr/bin/catdoc
    11. Thu 2017-05-25 19:14:44 CEST 4969 1000 100 11 /usr/bin/catdoc
    12. Thu 2017-05-25 19:15:56 CEST 5083 1000 100 11 /usr/bin/catdoc
    13. Thu 2017-05-25 19:19:40 CEST 5287 1000 100 11 /usr/bin/catdoc
    14. Thu 2017-05-25 19:19:41 CEST 5294 1000 100 11 /usr/bin/catdoc
    15. Thu 2017-05-25 19:23:27 CEST 31064 1000 100 11 /usr/bin/catdoc
    16. Thu 2017-05-25 20:03:23 CEST 4139 0 0 11 /usr/lib/YaST2/bin/y2base
    17. Thu 2017-05-25 20:03:56 CEST 4229 0 0 11 /usr/lib/YaST2/bin/y2base
    18. Thu 2017-05-25 20:08:57 CEST 5021 0 0 11 /usr/lib/YaST2/bin/y2base
    19. Thu 2017-05-25 20:09:49 CEST 5168 0 0 11 /usr/lib/YaST2/bin/y2base
    20. Thu 2017-05-25 20:10:35 CEST 5654 1000 100 11 /usr/bin/catdoc
    21. Thu 2017-05-25 20:10:35 CEST 5656 1000 100 11 /usr/bin/catdoc
    22. Thu 2017-05-25 20:10:36 CEST 5658 1000 100 11 /usr/bin/catdoc
    23. Thu 2017-05-25 20:12:07 CEST 5745 0 0 6 /usr/lib/YaST2/bin/y2base
    24. Thu 2017-05-25 20:15:49 CEST 6080 0 0 6 /usr/lib/YaST2/bin/y2base
    25. Thu 2017-05-25 20:24:12 CEST 6297 0 0 11 /usr/lib/YaST2/bin/y2base
    26. Thu 2017-05-25 20:24:17 CEST 6616 1000 100 11 /usr/bin/catdoc
    27. Thu 2017-05-25 20:24:47 CEST 6406 0 0 11 /usr/lib/YaST2/bin/y2base
    28. Thu 2017-05-25 20:33:20 CEST 7290 1000 100 11 /usr/bin/catdoc
    29. Thu 2017-05-25 23:09:59 CEST 16450 1000 100 11 /usr/bin/catdoc
    30. Thu 2017-05-25 23:10:00 CEST 16452 1000 100 11 /usr/bin/catdoc
    31. Thu 2017-05-25 23:17:29 CEST 16851 1000 100 11 /usr/bin/catdoc
    32. Thu 2017-05-25 23:31:02 CEST 17379 1000 100 11 /usr/bin/catdoc
    33. Thu 2017-05-25 23:33:00 CEST 17464 1000 100 11 /usr/bin/catdoc
    34. Thu 2017-05-25 23:48:20 CEST 18075 1000 100 11 /usr/bin/catdoc
    35. Fri 2017-05-26 00:39:15 CEST 20101 1000 100 11 /usr/bin/catdoc
    36. Fri 2017-05-26 00:50:31 CEST 20551 1000 100 11 /usr/bin/catdoc
    37. Fri 2017-05-26 00:52:16 CEST 20625 1000 100 11 /usr/bin/catdoc
    38. Fri 2017-05-26 00:57:00 CEST 20807 1000 100 11 /usr/bin/catdoc
    39. Fri 2017-05-26 01:02:36 CEST 21174 1000 100 11 /usr/bin/catdoc
    40. Fri 2017-05-26 01:02:42 CEST 21187 1000 100 11 /usr/bin/catdoc
    41. Fri 2017-05-26 01:04:35 CEST 21324 1000 100 11 /usr/bin/catdoc
    42. Fri 2017-05-26 01:17:33 CEST 21849 1000 100 11 /usr/bin/catdoc
    43. Fri 2017-05-26 01:25:07 CEST 22141 1000 100 11 /usr/bin/catdoc
    44. Fri 2017-05-26 01:31:25 CEST 22445 1000 100 11 /usr/bin/catdoc
    45. Fri 2017-05-26 01:40:11 CEST 22771 1000 100 11 /usr/bin/catdoc
    46. Fri 2017-05-26 05:42:19 CEST 2156 1000 100 11
    47. Fri 2017-05-26 13:00:13 CEST 432 0 0 11 /usr/lib/YaST2/bin/y2base
    48. Fri 2017-05-26 13:06:30 CEST 1187 0 0 6 /usr/bin/ruby
    49. Fri 2017-05-26 13:08:04 CEST 1594 0 0 11 /usr/lib/YaST2/bin/y2base
    50. Fri 2017-05-26 14:47:23 CEST 6258 0 0 6 /usr/bin/ruby
    51. Fri 2017-05-26 14:48:36 CEST 6653 0 0 6 /usr/bin/ruby
    52. Fri 2017-05-26 14:49:11 CEST 6726 0 0 6 /usr/bin/ruby
    53. Fri 2017-05-26 14:51:19 CEST 7074 0 0 6 /usr/bin/ruby
    54. Fri 2017-05-26 19:09:58 CEST 253 0 0 11 /usr/sbin/plymouthd
    55. Fri 2017-05-26 19:12:03 CEST 244 0 0 11 /usr/sbin/plymouthd
    56. Fri 2017-05-26 20:16:10 CEST 250 0 0 11 /usr/sbin/plymouthd
    57. Fri 2017-05-26 20:45:58 CEST 252 0 0 11 /usr/sbin/plymouthd
    58. Sat 2017-05-27 08:14:57 CEST 248 0 0 11 /usr/sbin/plymouthd
    59. Sat 2017-05-27 14:04:23 CEST 19728 1000 100 11 /usr/lib64/firefox/plugin-container
    60. Sun 2017-05-28 10:10:51 CEST 3344 1000 100 11
    61. Sun 2017-05-28 12:26:19 CEST 19561 1000 100 11 /usr/lib64/firefox/plugin-container
    62. Tue 2017-05-30 16:25:07 CEST 22685 1000 100 11 /usr/lib64/firefox/plugin-container
    63. Tue 2017-05-30 16:25:18 CEST 4426 1000 100 11 /usr/lib64/firefox/plugin-container
    64. Tue 2017-05-30 16:35:42 CEST 19058 1000 100 11 /usr/lib64/firefox/plugin-container
    65. Tue 2017-05-30 18:46:17 CEST 20186 1000 100 11 /usr/lib64/firefox/plugin-container
    66. Sun 2017-06-11 18:16:08 CEST 15852 1000 100 11 /usr/bin/perl
    67. Sun 2017-06-11 18:17:23 CEST 15906 1000 100 11 /usr/bin/perl
    68. Wed 2017-06-14 17:07:26 CEST 24178 1000 100 11 /usr/lib64/firefox/plugin-container
    69. Sun 2017-06-18 12:56:18 CEST 29559 1000 100 6 /usr/bin/vlc
    70. Sun 2017-06-18 12:56:28 CEST 29591 1000 100 6 /usr/bin/vlc
    71. Sun 2017-06-25 10:27:56 CEST 248 0 0 11 /usr/sbin/plymouthd
    72. Sun 2017-06-25 19:32:58 CEST 3138 1000 100 11
    73. Tue 2017-06-27 16:37:24 CEST 12077 1000 100 11 /usr/bin/perl
    74. Tue 2017-06-27 16:38:42 CEST 12129 1000 100 11 /usr/bin/perl
    75. Tue 2017-07-11 18:02:10 CEST 240 0 0 11 /usr/sbin/plymouthd
    76. Sun 2017-07-16 20:08:28 CEST 13720 1000 100 11
    77. Wed 2017-07-19 20:08:24 CEST 25949 1000 100 11 /usr/bin/perl
    78. Wed 2017-07-19 20:09:31 CEST 26009 1000 100 11 /usr/bin/perl
    79. Wed 2017-07-19 20:10:24 CEST 26075 1000 100 11 /usr/bin/perl
    80. Wed 2017-07-19 20:11:56 CEST 26125 1000 100 11 /usr/bin/perl
    81. Wed 2017-07-19 20:12:54 CEST 26191 1000 100 11 /usr/bin/perl
    82. Wed 2017-07-19 20:14:29 CEST 26244 1000 100 11 /usr/bin/perl
    83. Fri 2017-07-28 15:11:18 CEST 2632 1000 100 11
    84. Fri 2017-07-28 18:50:01 CEST 23618 1000 100 11 /usr/bin/xembedsniproxy
    85. Fri 2017-07-28 19:57:25 CEST 32751 1000 100 11 /usr/bin/perl
    86. Sat 2017-07-29 11:53:19 CEST 31441 1000 100 11 /usr/bin/perl
    87. Sat 2017-07-29 11:55:38 CEST 31496 1000 100 11 /usr/bin/perl
    88. Sat 2017-07-29 11:56:02 CEST 31645 1000 100 11 /usr/bin/perl
    89. Sat 2017-07-29 11:56:53 CEST 31681 1000 100 11 /usr/bin/perl
    90. Sat 2017-07-29 18:20:32 CEST 17526 1000 100 11 /usr/bin/perl
    91. Sat 2017-07-29 18:21:33 CEST 17625 1000 100 11 /usr/bin/perl
    92. Sat 2017-07-29 18:22:15 CEST 17670 1000 100 11 /usr/bin/perl
    93. Sat 2017-07-29 18:23:43 CEST 17714 1000 100 11 /usr/bin/perl
    94. Sat 2017-07-29 18:24:35 CEST 17808 1000 100 11 /usr/bin/perl
    95. Sat 2017-07-29 18:25:17 CEST 17855 1000 100 11 /usr/bin/perl
    96. Sun 2017-07-30 14:39:43 CEST 8149 1000 100 11 /usr/bin/perl
    97. Sun 2017-07-30 18:03:30 CEST 17002 1000 100 11 /usr/bin/perl
    98. Sun 2017-07-30 18:04:29 CEST 17051 1000 100 11 /usr/bin/perl
    99. Sun 2017-07-30 18:05:48 CEST 17105 1000 100 11 /usr/bin/perl
    100. Sun 2017-07-30 18:06:54 CEST 17175 1000 100 11 /usr/bin/perl
    101. Sun 2017-08-06 15:42:49 CEST 3677 1000 100 11
    102. Mon 2017-08-07 11:24:58 CEST 8223 1000 100 11 /usr/bin/perl
    103. Wed 2017-08-09 14:10:06 CEST 1965 1000 100 11 /usr/bin/perl
    104. Wed 2017-08-16 16:51:25 CEST 28824 1000 100 11 /usr/bin/perl
    105. Wed 2017-08-16 16:52:14 CEST 28915 1000 100 11 /usr/bin/perl
    106. Wed 2017-08-16 16:53:21 CEST 28964 1000 100 11 /usr/bin/perl
    107. Wed 2017-08-16 16:54:07 CEST 29063 1000 100 11 /usr/bin/perl
    108. Wed 2017-08-16 16:57:23 CEST 29114 1000 100 11 /usr/bin/perl
    109. Wed 2017-08-16 17:11:18 CEST 30592 1000 100 11 /usr/bin/perl
    110. Wed 2017-08-16 17:11:52 CEST 30705 1000 100 11 /usr/bin/perl
    111. Wed 2017-08-16 17:23:31 CEST 32120 1000 100 11 /usr/bin/perl
    112. Fri 2017-08-25 15:58:57 CEST 21354 1000 100 11 /usr/bin/perl
    113. Sat 2017-08-26 16:47:50 CEST 5082 1000 100 11 /usr/bin/perl
    114. Sat 2017-08-26 17:19:39 CEST 6320 1000 100 11 /usr/bin/perl
    115. Sat 2017-08-26 17:21:00 CEST 6384 1000 100 11 /usr/bin/perl
    116. Sat 2017-08-26 17:22:31 CEST 6467 1000 100 11 /usr/bin/perl
    117. Sat 2017-08-26 17:23:17 CEST 6520 1000 100 11 /usr/bin/perl
    118. Sun 2017-09-03 08:53:56 CEST 26779 1000 100 11 /usr/bin/simple-scan
    119. Sun 2017-09-03 09:30:28 CEST 28974 1000 100 6 /usr/bin/vlc
    120. Mon 2017-09-11 05:16:32 CEST 10966 1000 100 11 *
    121. Mon 2017-09-11 18:21:41 CEST 2535 1000 100 11 *
    Alles anzeigen



    Quellcode

    1. linux-bik2:/etc # lsb-release -a
    2. LSB Version: n/a
    3. Distributor ID: openSUSE project
    4. Description: openSUSE Leap 42.2
    5. Release: 42.2
    6. Codename: n/a
    7. linux-bik2:/etc # /sbin/lspci -nnk | grep -iA3 net
    8. 02:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] [8086:0082] (rev 34)
    9. Subsystem: Intel Corporation Centrino Advanced-N 6205 AGN [8086:1301]
    10. Kernel driver in use: iwlwifi
    11. Kernel modules: iwlwifi
    12. 05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
    13. Subsystem: Fujitsu Limited. Device [10cf:16af]
    14. Kernel modules: r8169
    Alles anzeigen


    Nachtrag:
    eth0 ist wieder da; wahrscheinlich wegen dem hier: collectNWDataGUI.sh

    Danke

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von oracle123 ()

    Für den Inhalt des Beitrages 112619 haftet ausdrücklich der jeweilige Autor: oracle123

  • OK!

    So, jetzt wieder zum eigentlichen Thema: dem kworker; aktuell sind es:


    Quellcode

    1. linux-bik2:/etc # ps -ef | grep kworker | wc -l
    2. 30
    Prozesse.

    Werde das System noch einige Tage beobachten, und dann hoffentlich als erledigt markieren!

    Danke!

    Für den Inhalt des Beitrages 112627 haftet ausdrücklich der jeweilige Autor: oracle123

  • Bei mir laufen 15 kworker Prozesse von root mit 0% Cpu und 0 Speicher.

    Sie lassen sich nicht beenden und auch nicht killen.

    Elternprozess ist kthreadd läßt sich auch nicht beenden oder killen.
    (auch nicht als root mit icewm)

    Manchmal verschwindet ein Prozess und ein anderer kommt.

    Manchmal kommt bei einem Prozess die Meldung "disk sleep" und geht wieder.

    Manchmal kommt bei einem Prozess die Meldung "inaktiv auf Festplatte" und geht wieder.

    kworker hat etwas mit Speichermedien zu tun, und benötigt bei mir keine Ressourcen.

    Ich denke, wir sollten kworker einfach seine Arbeit machen lassen!

    Für den Inhalt des Beitrages 112661 haftet ausdrücklich der jeweilige Autor: Kanonentux

  • kworker sind Arbeitsprozesse des Kernels. Sie sind NICHT direkt einem Programm oder einer Funktion zuordenbar.
    Im wesentlichen lässt der Kernel von einem solchen Worker-Prozess einen System-Request abarbeiten. Meist durch einem Interrupt aufgerufen.

    Tritt ein solcher SysRequest auf, wissen wir noch lange nicht, was diesen Request ausgelöst hat.
    Wir wissen nur, dass ein Interrupt gerufen wurde, und die unmittelbare Reaktion des Systems verlangt worden ist.
    Dem Kernel ist das alles erst mal völlig egal.
    Er ruft für diesen Interrupt die zugehörige Serviceroutine auf, eben einen solchen kworker, und kümmert sich vorerst gar nicht weiter darum.

    Meist wird dann irgendein Hardwareereignis verarbeitet.
    Die Mouse wurde geschubst, die Netzwerkkarte gepingt, der Akku demonstriet gewalttätig für mehr Lohn und Nahrung,
    der Bildschirm hat keinen Bock mehr und hisst den Trauerflor.
    Was auch immer, wir wissen es nicht.

    Die jeweiligen kworkers tun ihre Arbeit und erklären dem Akkuwatchdog, dass der Oberlooser jetzt benachrichtigt wird.
    Die Netzwerkkarte wird von dem Pingpaket entlastet, eine Antwort gesendet und der Krempel gelöscht.
    Dem Bildschirm wird der Saft abgedreht.
    Der Mousezeiger wird rumgeschubst.

    Das ganze ist im ACPI verankert. (AdavancedConfigurationandPowerInterface)
    Es geht also um die gesamte Hardware und das Powermanagement.

    Man kann einem solchen Übeltäter auf die Spur kommen, wenn man top oder dergleichen laufen lässt
    Wenn man sieht, dass die Last richtig hoch geht, drückt man in einer weiteren Konsole <enter> um den schon eingegeben Befehl echo l > /proc/sysrq-trigger auszuführen. Der veranlasst einen Backtrace, der dann Aufschluss geben kann, was denn die Ursache sein könnte.
    Man muss das schon mehrmals machen, um den oder die Schuldigen zu finden. Man lese alles, was nach dem getriggerten Backtrace erscheint.
    Was am häufigsten auftaucht, wird der Grund für die Last sein.
    Mitlesen tut man den Krempel am besten in einer dritten Konsole, wo der Befehl journalctl -f dann beständig Unverständliches blubbert.
    Dazu muss man jedoch schon ein wenig mehr von Hardware und den jeweiligen Akronymen für die Hardware verstehen.
    Dass ein NMI ein NichtMaskierbarerInterrupt ist, ist noch Kindergartenwissen. Mittlere Reife sollte man schon haben.
    Etwas bequemer wäre wohl performance, was aber erst mit zypper in perf installiert werden will.
    Mit perf record -g -a sleep 10 erstellt man einen 10 Sekunden langen Log aller Prozessoren und mit perf report kann man dann gemütlich nachlesen, was da so passiert ist. ( Die Cursortasten zum Navigieren, <enter> um eine Zeile dann aufzuklappen und etwas mehr Infos zu lesen)

    In diesen Traces findet sich am Anfang (also nach Datum/Zeit und Hostname am Anfang der eigentlichen Meldung) dann immer der Kernelmodulname, das dafür verantwortlich ist. Ein beherztes rmmod <modulname> und die Load sollte schlagartig zurückgehen.
    Dann weiß man, wo man zu graben hat, falls man das dann überhaupt noch lesen kann und nicht zum Hardreset gezwungen ist.

    Etwas leichter und weniger Wissen fordernd mag die etwas rustikale Methode sein:
    In /sys/firmware/acpi/interrupts/ sind alle Genossen gelistet, die als Ursache in Frage kommen können.
    Mit dem Befehl grep -r . /sys/firmware/acpi/interrupts/ erhält man eine Liste mit der Anzahl der Interrupts.
    Der Befehl ist etwas schräg:
    grep Mit dem GlobalRegularExpressionPrinter suchen wir
    -r rekursiv (also in allen Dateien einschliesslich aller Unterverzeichnisse)
    . nach einem beliebigen Zeichen in dem Verzeichis
    /sys/firmware/acpi/interrupts/
    Da der grep Befehl bei -r den Pfadnamen der Datei mit ausgibt, haben wir danach die Dateinamen mit der zugehörigen Zeile (Dort ist immer nur eine Zeile mit der Anzahl und in der suchen wir ein beliebiges Zeichen, was wir auf jeden Fall finden.), und können so bequem lesen, welcher dieser Interrupts am häufigsten gerufen wurde.
    Eine solche Fundzeile mag so aussehen:
    /sys/firmware/acpi/interrupts/gpe39: 0 invalid
    Damit wäre der Interrupt Nummer gpe39 unser Target.

    Und den schalten wir einfach aus mit: echo disable > /sys/firmware/acpi/interrupts/gpe39
    Die Last sollte auch da schlagartig runter gehen, oder man muss weiter suchen, falls man das noch kann.

    Die Verzeichnisse /sys und /proc sind Pseudodateisysteme. Statt in "echte" Dateien zu schreiben, schreiben wir direkt in die Kerneldatenstrukturen, oder lesen daraus.
    Getreu dem heiligen *nix Dogma: Alles ist eine Datei

    Keine Angst vor dem Kernel!
    Immer feste druff!

    Mehr als stehen kann das System nicht.
    Und auf ein Neues, und sofort wieder feste druff!!!
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 112666 haftet ausdrücklich der jeweilige Autor: Berichtigung

www.cyberport.de