samedi 24 novembre 2012

lennart's day : pulseaudio, systemd, initials and misconfigured system

I stumbled upon some kind of leak. /var/log/journal is eating 2GB. That explains why journalctl is sluggish as hell.

luser@x60s_GPT ~ % journalctl | awk '{print $5}' | sed 's,[^a-zA-Z\-],,g' > log
# 2 hours and 22MB later

luser@x60s_GPT ~ % sort log | uniq -c | sort -nr | head
1953078 pulseaudio
  62863 kernel
  39051 systemd
  14992 sudo
  14463 udisks-daemon
   7923 USRSBINCROND
   4015 usrsbincrond
   1601 dhcpcd
    733 systemd-logind
    704 systemd-journal


So pulseaudio is the prime suspect. A while back I used '-vvvv' for debugging purposes, but removed the vvvverbose option for at least a few weeks. It was dropping dozens of messages every 5 seconds and I can't find a way to trim the old persisted logs. I'm tempted to blindly delete them but will wait a bit before doing so.

tl;dr still looking for a way to manage, meaning trim, systemd journal disk usage a posteriori in case of log bloat.

Trivia: journal log header include LPKSHHRH. I thought it was a compression format magic number, PKZIP comes to mind, but apparently it is more of a signature.


LPKSHHRH acronym
LP KS HH RH ;)






ha, computers. I mean noobs.

dimanche 18 novembre 2012

correcting pacman scriptlet syntax error with gdb

On Nov 18 2012, archlinux openntpd-3.9p1-20-i686 package install script had a syntax error. An empty bash function (it seems) caused upgrade abortion. I thought I could intercept package decompression so that I can correct the script but pacman is fine grained and clean everything as soon as it can. So I used that as an excuse to mess with it using gdb. I never ran a real program in gdb before, not even one without debugging symbols, so it wasn't a breeze. After 10 minutes of useless `continue` I tried to locate function calls of interest. Not knowing the linux C ecosystem I started with a guess `mkdir`, then saw `mkdtemp`. I was monitoring /tmp for new entries made by pacman. But by the time I see a .INSTALL it's already too late. After poking through pacman github's repo, I saw new names but these are non loaded shared libraries and I don't understand how to declare a breakpoint on these. Anyway the script execution is done in a forked process, so the .INSTALL file still exists at the time a `b fork` will pop, that's where vim comes into play for a little on-the-fly monkeypatch.

tl;dr: gdb breakpoints on mkdtemp and fork leaves an open window to edit pacman's .INSTALL script, and successfully install this package, one that people on #archlinux consider obsolete, too late, I'll brag anyway.

references:

https://projects.archlinux.org/pacman.git/tree/lib/libalpm/util.c

edit: few wordings, and forgot the end. * facepalm *

jeudi 8 novembre 2012

About Desktop Environments, *nix, asynchronous monitoring

Simplest reactive UI, the unix way ?


I was happy when I saw KDE4 and recent Gnome DE include sophisticated notifications system (finally) but field testing wasn't so good. Using a not so recent ThinkPad laptop, I aimed toward a simpler, lighter graphical interface, namely Xmonad/Xmobar in almost vanilla state. Being new to haskell, and to tweaking a basic (arch)linux, I delayed for many monthes until I finally eat it.
Adding a bunch of sensors to xmobar/dzen is easy. dzen even handles mouse events so you can have active notifications. There's also dunst to pop notification bubbles when you need it, where you need it. Basically with the right amount of pretty-good glue, you'd have enough asynchronousness to monitor secondary tasks without needing anything more than 2 simple programs.

to be continued...