Ifupdown and Command Status Handling

In 2011, I first tried to fix a Debian bug #547587. The bug was about hook script result codes not being checked, so if a script fails, this isn’t detected. Unfortunately, just checking the return code wasn’t enough, as lots of scripts didn’t care about their return code at all, so I had to unapply the patch.

Now, after 2.5 years, I think it’s time to try again, as most of the scripts have been fixed since then. At the same time, I’ve changed error handling a little bit further: errors in any commands or scripts during interface configuration are considered fatal, but when interface is deconfigured, errors are ignored. However, this may change break configurations which depend on previous behaviour.

Please report bugs if you find any.


Hgk Misbehaviour With Tk 8.4

Strangely enough, running hgk (a port of gitk to Mercurial, also known as hg view) with Tk 8.4 crashes my X server. Updating both Tk and the X doesn’t help. I don’t feel like I want to debug X now, but probably that’s what I have to do :(

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x49) [0xb7712ed9]
1: /usr/bin/X (0xb7572000+0x1a4c64) [0xb7716c64]
2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb755040c]
3: /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb711d000+0x772f0) [0xb71942f0]
4: /lib/i386-linux-gnu/i686/cmov/libc.so.6 (__libc_calloc+0xab) [0xb7196d5b]
5: /usr/bin/X (0xb7572000+0x55ca9) [0xb75c7ca9]
6: /usr/bin/X (0xb7572000+0x48005) [0xb75ba005]
7: /usr/bin/X (0xb7572000+0x491c3) [0xb75bb1c3]
8: /usr/bin/X (0xb7572000+0x12c621) [0xb769e621]
9: /usr/bin/X (XkbHandleActions+0x20b) [0xb76c8c1b]
10: /usr/bin/X (XkbProcessKeyboardEvent+0xbc) [0xb76c937c]
11: /usr/bin/X (AccessXFilterPressEvent+0xcd) [0xb76c181d]
12: /usr/bin/X (0xb7572000+0x157675) [0xb76c9675]
13: /usr/bin/X (mieqProcessDeviceEvent+0x1e6) [0xb76f3226]
14: /usr/bin/X (mieqProcessInputEvents+0xfd) [0xb76f335d]
15: /usr/bin/X (ProcessInputEvents+0x14) [0xb75ef3e4]
16: /usr/bin/X (0xb7572000+0x3c25d) [0xb75ae25d]
17: /usr/bin/X (0xb7572000+0x2a51a) [0xb759c51a]
18: /lib/i386-linux-gnu/i686/cmov/libc.so.6 (__libc_start_main+0xf5) [0xb71368c5]
19: /usr/bin/X (0xb7572000+0x2a8f8) [0xb759c8f8]

Process Isolation Support in Start-stop-daemon

Yesterday I played with LXC a bit, and I liked it, as LXC provides a very lightweight isolation of processes, much like enchanced chroot. However, I realised, I don’t always need the chroot-like part of LXC, sometimes what I need is just to make sure the process is unable to see the other processes and talk to them in any other way except the filesystem, but I don’t want a whole separate root file system for that. LXC provides a simple utility, lxc-unshare, which uses Linux-specific clone(2) call to run a process with new PID, IPC and other namespaces. However, this utility can’t be used for running forking daemons, as the container is destroyed when its PID 1 exits.

That’s why I decided to add the support for process isolation to start-stop-daemon. I was careful enough to introduce minimal changes to it to make sure they can be merged back to the version as shipped with dpkg, and at the same time be buildable separately from the rest of it. Speaking of building, by the way, this version of start-stop-daemon uses mk-configure, a light-weight autotools replacement, as its build system.

What I added, from a user’s perspective, is a single --isolate option. When run with this option, start-stop-daemon calls clone(2) just before configuring the environment of a process it’s going to run. The cloned process runs in a new namespace, and immediately remounts /proc, /dev/shm and /dev/mqueue. Then it forks, and a forked process executes the daemon. The parent process, which is PID 1 in the new PID namespace, uses waitpid(2) to monitor its child processes. As soon as its very first child exits, it talks via a pipe to the process outside of the container, so that it knows the container has a forked daemon and it needs to detach. In any case, the container’s PID 1 does waitpid(2) in a loop, checking the process list every time a child terminates. As soon as it’s left alone or a SIGTERM is received, it exits.

The code is published at Bitbucket.


Clearlooks-Phénix Update

Once upon a time, GTK+ 3.0 was released. That release brought at least one Bad Thing™: incompatibility with GTK+ 2.x themes. At the same time, previously popular Clearlooks theme hasn’t been ported. Many people didn’t like that, but only one decided to DTRT — to do the Right Thing. Jean-Philippe Fleury wrote Clearlooks-Phénix (originally, Clearwaita), a GTK+ 3 theme which was supposed to have a look and feel as close as possible to the original Clearlooks. He based his work on an engine of a new GTK+ default, Adwaita theme. Quite soon, however, GTK+ 3 theme API has changed, and it became easily possible to rewrite the theme without using any additional theming engines, with just plain GTK+ stuff involved.

Then GTK+ 3.6 came and broke the API once more. Jean-Philippe fixed stuff to work with newer GTK+ again, and everyone was happy again.

But Empire striked back: GTK+ 3.8 brought more disruptive changes, rendering menus as ugly as never before. Unfortunately, Jean-Philippe was unable to cope with changes alone, he set up a mailing list to collectively develop Clearlooks-Phénix, but that didn’t help, and no fix has been released during more than half a year.

As a maintainer and a user of Clearlooks-Phénix, I had to do something with this, as more and more things needed recent GTK+ 3 to work. After spending some time studying CSS code and playing with its knobs, I found a solution which proved to be quite simple, and uploaded an updated package. Unfortunately, the changes aren’t in the upstream package yet.

Now, with GTK+ 3.10, stuff is not quite working again. Some changes in GTK+ internals lead to menu bars not being coloured properly. At the moment of this writing, an updated package is already available in unstable.


Not Coming to FOSDEM

It turnes out moving to a different city takes more time and effort than I originally expected, so I’m skipping FOSDEM this year. That’s unlike I originally planned to spend the beginning of February — I had my flight booked already, but apparently that’s not the best idea ever to go travelling right in the middle of relocation :)


A Bit More on TrueCrypt

Few days ago I was discussing my last blog post with a colleague of mine, Lukaš Tvrdý, and he’s mentioned that it actually is possible to harmlessly decrypt the TrueCrypted filesystem in online mode, resize it, and encrypt it back again. Well, I decided to try, because I have had some problems with that setup. Apart from init script reordering I had to make (not covered in the post, as I did it later and haven’t found time yet to write about that), I ran into a trouble while trying to enable swapping. As the only partition I had was formatted into NTFS, placing a swap file there isn’t the best idea ever. I actually tried doing so, but after two deadlocks I had in few hours I had to rethink that. Indeed, as NTFS is implemented in the user space using ntfs-3g, as soon as this process gets swapped out, the system is left helpless. The swap is on the file system driver of which is in the swap, which is on the file system driver of which is… well, you get the idea.

Basically, I got rid of ext3-on-the-loop, and now I have real ext3 in a LUKS container, plus a separate swap partition. Now the other problem is: I still have an encrypted NTFS filesystem which I occasionally need to access, but I don’t want to type the pass phrase twice… Something to think about.


How to Run Debian From a Loop Device on a TrueCrypt’ed NTFS Partition

After I have changed my job recently I had to meet the security policies which are enforced in the company I’m now working for. First of all, I’m not allowed to use my own laptop, and the company-provided laptop has Windows installed. As my job is, unfortunately, not directly related to Linux, I’m not allowed to re-install the OS. However, working in the comfortable environment is what I really need to do my job effectively, so I have designed a workaround.


Bohdan Zograf and So-called “Belorussian” Translations

I’d like to bring some attention to activity of a person mostly known as Bohdan Zograf. If you Google that name, you’ll find that he seems to be a person who knows Belarusian language very well, and is interested in translating as many texts as he can into Belarusian for no money. Unfortunately, he isn’t. Trust me, I’m really a native speaker, I was born in Minsk, Belarus, and have lived there for 25 years of my life (at least this person: (1, 2) may prove I really am the person I’m telling you I am, if you’re interested). Said that, I think I really have a right to say: those translations are fake. These texts are just machine-translated versions of the original articles or web pages, published in some strange weblog at some strange web site without being structured or systematised. This already has been pointed out by Jonathan Wakely, but, well, some people may not believe him as he doesn’t seem to know Belarusian.

Anyway, one more interesting detail: why would a person with a non-Belarusian name and a Hungarian telephone number who can’t really properly spell the name of the country (Belarus, not Belorussia) and the language (Belarusian, not Belorussian — well, lots of people do that mistake, I must admit), say that Belarusian is his mother tongue do a translation asking to link him back for that? Doesn’t that seem strange a bit? It does for me.

I don’t really understand the reasons behind that, and I can’t really see what is he going to achieve by doing this, but, as Jonathan said, I believe that all spammers must die. Well, not necessarily literally, but at least they must stop spamming, shouldn’t they?

Bohdan Zograf is a spammer. Don’t do what he asks you to do, as doing so you help spammers.

P.S. Spread the word.


Linux, Snd_hda_intel and Sigmatel STAC9200

Strange and interesting thing has happened to me recently. I’m a user of Dell D620 laptop, which has Intel’s HDA controller and Sigmatel’s STAC9200 codec. This has always worked perfectly fine, and in my mixer I could see at least two volume controls: Master and PCM. Changing volume using both worked.

Once I’ve upgraded my Linux 3.2 to 3.4, and have noticed that Master volume control is no more. What’s up I thought, but did nothing. Update to 3.5 hasn’t fixed the problem. Okay, it’s time to bisect stuff.


Removing Accounts From Android Devices

It’s a well-known problem that Android offers no easy way to completely remove the primary Google account, at least sometimes.

Well, there’s one not really easy for people not involved with computer stuff, but at least it works.

Once you have adb shell working, you need to log into your Android device and type sqlite3 /data/system/accounts.db. That’s the place where accounts are actually stored. In that database, there are tables named accounts, grants and authtokens. Those you need to clean up:

SQLite version 3.5.9
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select _id,name from accounts;
1|user@gmail.com
sqlite> delete from authtokens where accounts_id=1;
sqlite> delete from grants where accounts_id=1;
sqlite> delete from accounts where _id=1;
sqlite> select _id,name from accounts;

After that it may be a good idea to restart the device, but I’m not sure it’s really needed.