Iotop
Posted by bene - 30/06/08 at 11:06:55 pmOne of the drawbacks of top is that it often can’t help to spot processes which push up system load so high.
High system loads are often caused by very I/O intensive tasks.
And as I/O intensive needn’t mean CPU intensive, those tasks may not even show up in top.
This is where Iotop comes into play. It is just a python script which evaluates the per-task disk I/O accounting statistics exported by the Linux kernel (2.6.20+).

This is what you need to enable in your kernel configuration:
General setup
[*] Export task/process statistics through netlink (EXPERIMENTAL)
[ ] Enable per-task delay accounting (EXPERIMENTAL)
[*] Enable extended accounting over taskstats (EXPERIMENTAL)
[*] Enable per-task storage I/O accounting (EXPERIMENTAL)
Linux kernel 2.6.25.6
Posted by bene - 09/06/08 at 09:06:15 pmChris Wright just pushed version 2.6.25.6 to the current stable kernel tree.
It’s definitely worth to check it out: There are 50 commits since 2.6.25.5, many of them backports of bugfixes in 2.6.26-rcx…
Happy compiling ![]()
Root exploit for Linux 2.6.24.1
Posted by micele - 11/02/08 at 12:02:34 pmIt’s time for a new local root exploit on the linux kernel. Two exploits have been reported. Both are based on leaky dealing with pointers regarding the function vmsplice, brought in by kernel release 2.6.17. For this reason one of the exploits works for all kernel versions from 2.6.17 to 2.6.24.1. Kernel Bug Tracker says:
Both exploits cause kernel Oops or (randomly) give root privilegies to the user.
A new kernel version 2.6.24.2 has been released and the regarding changelog reports a kind of fix. But comments like
But we also must check whether we can access the actual memory region pointed to by the struct iovec to fix the access checks properly.
still don’t sound like 100% fixed and reliable…
Linux 2.6.24
Posted by bene - 26/01/08 at 10:01:16 pmAm Donnerstag Abend wurde Version 2.6.24 vom Linux Kernel veröffentlicht.
Spektakulär ist dieses Release nun wirklich nicht – Linus hat ihm noch nicht mal einen eigenen Namen spendiert. Dafür gibt es aber einige kleinere Änderungen unter der Haube.
Wer sich den Kernel selbst baut, wird vermutlich zunächst seine Konfigurationsdatei .config mit make oldconfig an die aktuelle Version anpassen.
Im Laufe der Zeit ist diese Datei einigen Änderungen unterzogen, die durch verschiedene Kernel Versionen und geänderte Hardware notwendig werden. Möchte man diese Änderungen aufzeichnen, bietet sich das Versionsverwaltungssystem Git an. Git wird nicht nur vom Kernel selbst verwendet, sondern wurde sogar extra für das verteilte Entwicklungsmodell von Linux entworfen.
Jeder Entwickler pflegt dabei seine vollkommen eigenständige Version und tauscht lediglich seine Änderungen über Email, SSH, git:// o.a. mit den anderen Entwicklern aus. Dem liegt eine sehr ausgereifte Möglichkeit zum Erstellen und Verschmelzen von verschiedenen Entwicklungszweigen zu Grunde (branching / merging). Genau diese Möglichkeit kann man sich auch für das Versionieren seiner .config Datei zu Nutze machen.
Nachdem man sich eine Kopie vom offiziellen Kernel erstellt hat…
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git /usr/src/linux-git
…muss zunächst in der Liste der ignorierten Dateien (.gitignore) die Zeile
!.config
eingefügt werden, damit man die sonst ignorierte .config Datei (mit einer sinnvollen Bezeichnung) aufnehmen kann:
git add .config
git commit -am "added .config for v2.6.24"
Um z.B. Änderungen aus dem offiziellen Kernel zu übernehmen (z.B. beim v2.6.25 Release), reicht bereits ein
git pull
aus. Auch zum Editieren, Hinzufügen, Vergleichen, Publizieren, Zurücksetzen, … bringt Git eine sehr umfangreiche Liste an Werkzeugen mit, die grundsätzlich den Möglichkeiten von CVS oder Subversion ähneln.
Wessen Interesse an Git nun geweckt wurde, der möge sich dieses nette Tutorial anschauen, um in die restlichen 99.9% der Git Features eingeführt zu werden.
Powered by WordPress with GimpStyle Theme design by Horacio Bella. Get Entries and comments.