Wednesday, March 14, 2007

Printing Acrobatics

It took a whole evening of my life to get Acrobat Reader 7 to print on my box. I've installed it from the Debian Multimedia Packages Repository, soon after installing Debian, and only recently needed to print a document.

The printing dialog box shows the correct printer, but nothing happens when I try to print. I noticed that acroread uses the lpr command to print, so I opened a terminal and tried to print a text document with lpr. No luck. I used lpq to look at the print job queue and verified that the print job exists. The CUPS job queue, however, was empty.

I've managed to print by installing gtklp and using that as the printing command in acroread. But acroread keeps reverting to lpr after being restarted. I still haven't figured out how to fix it - and it's pretty annoying.

But I don't need to fix it, because I did manage to get lpr working. I stumbled upon, followed their instructions, and installed cupsys-bsd. This replaced lpr with a CUPS aware version, which made me happy again.

Being clueless can be very time consuming when it comes to using Linux. Making sense of it on your own often takes a lot of time and effort. It may be worth it, experience wise, but I do pretend to have a life, and episodes like this one just burst my bubble.

As for the document - I had no time to read it...

Friday, March 9, 2007

The Case of the Slow Scanner

The problem: scanner access was very slow. All the SANE front-ends that I tried got stuck for more than a minute, while "scanning for devices".

Troubleshooting: my initial suspicion was that the sane configuration at /etc/sane.d/ was somehow messed up. But this was a dead end. Using strace I found out that hpssd (the HPLIP services and status daemon) was the culprit: it was stuck waiting on a socket. But what was it waiting for?

I followed the troubleshooting procedure at the HPLIP site and started hpssd in debug mode. I then realized that hpssd was waiting for hpiod (the input/output daemon?) to find devices connected to the parallel port, probably timing out, and only then querying for USB devices (I pieced this theory together from a bunch of cryptic debug messages that hpssd spewed out while in debug mode). So, what next?

Solution: Searching through Google, I couldn't find any reference to a problem similar to mine. I did, however, encounter several hits that linked the parallel port mode with timeouts. So I set the parallel port mode to EPP via the BIOS, and the timeouts were gone, and scanner access became snappy.

The funny thing is that if anyone would've told me that I needed to change the parallel port mode in order to fix a problem with a USB scanner, I'd ignore the advice and prevent that person access to my computer...

Thursday, March 8, 2007

Mount Gigabyte

I'm using an external USB disk as the backup storage device for bacula. As usual, setting it up seemed easy enough at first, but got complicated later: after all, all I needed to do was connect the drive, and let hotplugging magic take over...

This didn't quite work - the file system on the disk is FAT32 and auto-mounting it meant that the user bacula was not permitted to access the disk. I needed to manually specify an entry for the disk in /etc/fstab as follows:

/dev/sda1 /mnt/gigapod vfat users,rw,noexec,nosuid,nodev,shortname=mixed,uid=bacula,gid=bacula,umask=000 0 0

This fixed the permissions issue, but caused two other problems. The most obvious problem was that the disk failed to mount during start up. Adding the noauto option to the mount options, and the following lines to do_start in /etc/init.d/, fixed it, by postponing the disk mounting very close to the end of the boot sequence:

# mount backup storage device and restart backup storage service

mount /mnt/gigapod
/etc/init.d/bacula-sd restart

The second issue that cropped up was that when other USB storage devices were connected, I would sometimes end up with /dev/sda1 pointing to one of the other storage devices. This was fixed by referring to the persistent device node name (courtesy of udev):

/dev/disk/by-id/usb-ExcelSto_r_Technology_J36_DEF1078555F6-part1 /mnt/gigapod vfat users,rw,noexec,nosuid,nodev,shortname=mixed,uid=bacula,gid=bacula,umask=000,noauto 0 0

It looks innocent enough, but it took me quite a while to get this working, which makes it worth documenting.

[23 Aug. 2007] Update: I now use udev rules to do this.

Sunday, March 4, 2007

Upstairs, Downstairs

Navigating the console command history can be tedious at times. One simple configuration I find very useful is binding the up/down keys to the backward/forward search functions of libreadline, by adding the following lines to ~/.inputrc:

$if mode=emacs

"\eOB": history-search-forward
"\e[B": history-search-forward
"\eOA": history-search-backward
"\e[A": history-search-backward

With this, just typing the first few characters of a command and hitting the up arrow key, will bring the previous command that starts with the already typed text. Now hitting up/down allows one to pick the right command from the history (hit ENTER to execute the line, or any other key to modify it).

This seems to work with any console based program that uses libreadline for keyboard input.