Some time ago I noticed that printing works somewhat strange on my desktop. It ran smoothly in most of the cases, but rarely it refuse to produce output. The really weird thing is that I didn’t know why it behaved in such a strange manner. As it is stated Murphy’s laws, it seem to fail when I was in a time-pressure situations. “Luckily”, One day, when my printer produced an error instead of doing its job, I had a time to solve the problem.
Analysis – user part
First of all, I needed to work out what is the real problem. I tried printing a few different documents. I selected those problematic and checked whether they are printable with other programs or configuration. The basic rules are:
- Repeatability and reproducibility – in what kind of situation does problem occur? Am I able to reproduce errors within doing the same steps? Does the problem repeat while using certain applications or it is document/configuration specific?
- Isolation – what kind of programs are involved? Pinpoint all of the programs and configuration files that could cause the problem.
My answers to this questions:
- Repeatability and reproducibility – the problem seems to be document specific. I found that it occur only within a small number of PDF and ps files.
- Isolation – printing program related to CUPS such as ghostscript, pnm2ppa, foomatic and CUPS itself.
Analysis – debugging
At first I looked up for logs (“/var/log/cups/error_log”). It wasn’t useful at all, however It suggested turning on the debugging mode. So I look into CUPS config (“/etc/cups/cupsd.conf”) and changed LogLevel to debug.
[code lang="bash"]
#LogLevel info
LogLevel debug
[/code]
I tried printing one of those baffling documents. I looked at errors and saw:
[code lang="bash"]
(...)
D [17/Apr/2007:22:15:56 +0200] [Job 151] GPL Ghostscript 8.54 (2006-05-17)
D [17/Apr/2007:22:15:56 +0200] [Job 151] Copyright (C) 2006 artofcode LLC, Benicia, CA. All rights reserved.
D [17/Apr/2007:22:15:56 +0200] [Job 151] This software comes with NO WARRANTY: see the file PUBLIC for details.
D [17/Apr/2007:22:15:56 +0200] [Job 151]
D [17/Apr/2007:22:15:56 +0200] [Job 151] Closing renderer
D [17/Apr/2007:22:15:56 +0200] [Job 151] Error: /VMerror in --stringwidth--
(...)
[/code]
So it is definitely a ghostscript error. I googled VMerror and found that it is a postscript error which means that my RIP (ghostscript in this case) doesn’t have enough memory. Because I have a lot of free RAM, it is probably a bug of ghostcript.
Solution
I simple searched for ghostscript alternatives in the portrage(“eix ghostscript”). I decided to switch from “ghostscript-GPL” to “ghostscript-esp” so I entered:
[code lang="bash"]
emerge --unmerge app-text/ghostscript-GPL
emerge app-text/ghostscript-esp
/etc/init.d/cups restart # restarting cups service
[/code]
After these steps printing services work properly.
I encountered a strange error while I was using subversion. I was checking out some of the programs sources while I got a message:
[code]
Fetching external item into 'koffice/kdgantt'
svn: PROPFIND request failed on '/home/kde/trunk/KDE/kdepim/kdgantt'
svn: PROPFIND of '/home/kde/trunk/KDE/kdepim/kdgantt': SSL negotiation failed: SSL disabled due to library version mismatch (https://svn.kde.org)
[/code]
As I had correctly installed subversion and openssl, I guessed that the linkage is the problem. That kind of problems should be removed by running revdep-rebuild. This time revdep didn’t help, so I re-emerge both programs manually. After that, svn worked as usual. The strange behaviour seems to be an issue of portrage’s ebuild.
I’ve decided to upgrade my Gentoo OS. I hadn’t done it before, because I’m using computer on a daily basis and I don’t want have computer frozen for about a day just to have KDE 3.5.5 instead of KDE 3.5.2. So I have to download and compile more than 1.3GB. It is too much for my computer to do it in a single shoot. So I decided to upgrade it within few steps (e.g. one night for X, …). Each evening, I used command (xyz is a package like xorg-server):
[code lang="bash"]
emerge -uN deep xyz; poweroff
[/code]
After one of that nights my kdm doesn’t appear after booting. Instead of it I saw an ugly xdm. Quick lookup to display 1 (Ctrl+Alt+F1) show an error:
[code]
which: no kdm in (/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.4.6:/opt/sun-jdk-1.4.2.12/bin:/opt/sun-jdk-1.4.2.12/jre/bin:/opt/sun-jdk-1.4.2.12/jre/javaws:/usr/qt/3/bin:/usr/games/bin)
[/code]
As I noticed there was no KDE paths in it. I guessed correctly that something with /etc/env.d/* has happened. I found on net that there should exist two files related to KDE in this directory:
In my file system a file /etc/env.d/*kdepaths* didn’t exist. So I created it.
Content of “/etc/env.d/45kdepaths-3.5″:
[code]
PATH=/usr/kde/3.5/bin
ROOTPATH=/usr/kde/3.5/sbin:/usr/kde/3.5/bin
LDPATH=/usr/kde/3.5/lib
CONFIG_PROTECT="/usr/kde/3.5/share/config /usr/kde/3.5/env /usr/kde/3.5/shutdown"
[/code]
Than I ran:
[code]
env-update
[/code]
And after that everything work as usual.
Today, I decided to set up internet sharing from workstation to my PPC. As my desktop PC and PDA have bluetooth, I wanted to use it instead of inconvenient USB cable.
Firstly, I look through Gentoo Linux documentation. I found two interesting articles, about bluetooth and routing. I follow them, which mean I rebuilt kernel, emerge a few programs and play for a while with configuration. From PPC side, I simple switch to static addresses and enter them. Everything worked as expected, till I decided to restart my computer. After that, I realised that bluetooth interface (bnep) didn’t have proper IP. The reason of that mistake was that script “/etc/bluetooth/pan/dev-up” hadn’t been execute. I double-checked permissions and name of that file, but it didn’t help. Documentation didn’t give me any clue. After some web searching, I noticed people who have the same problem, but unfortunately, I didn’t find solution.
At that moment, I decided to use some messy scripts to do that job. However, I still wondering, why my first method doesn’t work. I hope to figure it out.