New DTrace probes for the linuxu­lat­or

I for­ward por­ted my DTrace probes for the FreeBSD linuxu­lat­or from a 2008-​current to a re­cent -cur­rent. I have not the com­plete FreeBSD linuxu­lat­or covered, but a big part is already done. I can check the ma­jor locks in the linuxu­lat­or, trace fu­texes, and I have a D-​script which yells at a lot of er­rors which could hap­pen but should not.

Some of my D-​scripts need some changes, as real-​world test­ing showed that they are not really work­ing as ex­pec­ted. They can get over­whelmed by the amount of spec­u­la­tion and dy­nam­ic vari­ables (er­ror mes­sage: dy­nam­ic vari­able drops with non-​empty dirty list). For the dy­nam­ic vari­ables prob­lem I found a dis­cus­sion on the net with some sug­ges­tions. For the spec­u­la­tion part I ex­pect sim­il­ar tuning-​possibilities.

Un­for­tu­nately the D-​script which checks the in­tern­al locks fails to com­pile. Seems there is a little mis­un­der­stand­ing on my side how the D-​language is sup­posed to work.

I try to get some time later to have a look at those prob­lems.

Dur­ing my de­vel­op­ment I stumbled over some gen­er­ic DTrace prob­lems with the SDT pro­vider I use for my probes:

  • If you load the Linux mod­ule after the SDT mod­ule, your sys­tem will pan­ic as soon as you want to ac­cess some probes, e.g. “dtrace -l” will pan­ic the sys­tem. Load­ing the Linux mod­ule be­fore the SDT mod­ule pre­vents the pan­ic.
  • Un­load­ing the SDT mod­ule while the Linux mod­ule with the SDT probes is still loaded pan­ics the sys­tem too. Do not un­load the Linux mod­ule if you run with my patch.

Ac­cord­ing to avg@ those are known prob­lems, but I think nobody is work­ing on this. This is bad, be­cause this means I can not com­mit my cur­rent patch­set.

If someone wants to try the new DTrace probes for the linuxu­lat­or, feel free to go to http://​www​.Leidinger​.net/​F​r​e​e​B​S​D​/​c​u​r​r​e​n​t​-​p​a​t​c​h​es/ and down­load linuxulator-dtrace.diff. I do not of­fer a work­ing hy­per­link here on pur­pose, the SDT bugs can hurt if you are not care­ful, and I want to make the use of this patch a strong opt-​in be­cause of this. If the patch hurts you, it is your fault, you have been warned.

VDR ports docs

After a quick dis­cus­sion with nox@ I made a copy&paste of his “VDR is com­mit­ted now”-mail in­to the FreeBSD wiki. I also re-​styled some small parts of it to fit bet­ter in­to the wiki. It is not per­fect, but already us­able. Now in­ter­ested people can go and im­prove the docs there.

Thanks to Juer­gen for all his work in this area!

Con­vert­ing from Cour­i­er IMAP to dove­cot is easy

I have used Cour­i­er IMAP at home since a long time. As I want to up­date a dove­cot 1.2 setup to dove­cot 2.x, I de­cided to first have a look at dove­cot 2.x at home.

Switch­ing from Cour­i­er IMAP to dove­cot is really easy. I just con­figured the cor­rect path to the maildir, setup a passdb/​userdb, and it was work­ing.

The im­port­ant part was the cor­rect trans­fer of the pass­words. I used already an user­db in Cour­i­er IMAP with MD5 pass­words. For each user it has imappw=XXX with XXX sim­il­ar to $1$abc.

This can be con­ver­ted in­to a dove­cot passdb/​userdb line very eas­ily:


The cor­res­pond­ing passdb/​userdb set­tings for dove­cot are:

passdb {
   args = scheme=MD5-CRYPT username_format=%u /usr/local/etc/dovecot/dovecot.pws
   driver = passwd-​file
user­db {
   args = username_format=%u /usr/local/etc/dovecot/dovecot.pws
   driver = passwd-​file

Com­pared to when I had a look the last time, dove­cot is also able to use OTP as an au­then­tic­a­tion mech­an­ism now. Un­for­tu­nately I did not find any doc­u­ment­a­tion how to configure/​use it.

Non-​default linux base ports de­prec­ated

Yes­ter­day I de­prec­ated the non-​default Fe­dora based Linux base ports. This means fc6, f7, f8 and f9 will van­ish soon (I de­cided for one month of ex­piry time). This is be­cause all of them are End of Life up­stream since a long time (= no se­cur­ity up­dates).

The fc4 and f10 ones are still avail­able – even if they are End of Life too – be­cause FreeBSD 7.x can not use some­thing new­er than the fc4 one, and we have not tested yet a more re­cent Linux dis­tri­bu­tion.

Prob­ably the most easy way to up­date the Linux base ports to some­thing new­er is to stay with Fe­dora (we have a lot of ports-​infrastructure for it already). Un­for­tu­nately it is not known if some­thing new­er works without prob­lems (miss­ing epoll/​inotify sup­port could be a road­b­lock here in case it is ex­tens­ively used in a more re­cent ver­sion).

I want to get some time to have a look if a more re­cent Fe­dora ver­sion is suit­able for the use as a Linux base in FreeBSD 8.x+, but I do not have an es­tim­ate when I can start and how long it may take. In case someone already tested a more re­cent Fe­dora ver­sion feel free to share your ex­per­i­ence.