Bug#839785: am-utils: broken shutdown: amq -p causes abort, results in complete hang due to stale /net mount
Package: am-utils
Version: 6.2+rc20110530-3.2
Severity: critical
Justification: makes unrelated software on the system break (unrelated
processes hanging)
Hello,
I installed am-utils package today,
and then uninstalled it.
Was pretty astonished to find that
after package uninstall
unrelated processes started hanging (df etc.).
[the usual very annoying symptoms of stale mounts]
Thus figured out rather quickly that there was a stale mount left, despite
am-utils stop having been initiated by package uninstall already:
andi:(pid4532,port1022) on /net type nfs
(rw,relatime,sync,vers=2,rsize=1024,wsize=1024,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,noac,nolock,proto=udp,port=1022,timeo=7,retrans=3,sec=sys,local_lock=all,addr=127.0.0.1)
# sh -x /etc/init.d/am-utils stop
+ PATH=/usr/sbin:/sbin:/usr/bin:/bin
+ export PATH
+ CONF=/etc/default/am-utils
+ test -x /usr/sbin/amd
+ stop_amd
+ amq -p
+ pid=
+ [ -z ]
+ echo Stopping automounter: amd not running
Stopping automounter: amd not running
+ [ 0 -eq 0 ]
+ exit 0
[subsequent shutdown handling is thus completely and fully out-maneuvered]
I realized that in fact amd was not running any more at this point.
So, I re-start:ed the service.
At this point, manually doing
# strace -f amq -p
will show:
stat64("/usr/lib/cmov", 0xbfb262d0) = -1 ENOENT (No such file or
directory)
open("/usr/lib/libnss_db.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
stat64("/usr/lib", {st_mode=S_IFDIR|0755, st_size=86016, ...}) = 0
munmap(0xb771b000, 163182) = 0
open("/etc/protocols", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2932, ...}) = 0
read(3, "# Internet (IP) protocols\n#\n# Up"..., 1024) = 1024
close(3)= 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
gettimeofday({1475612569, 410100}, NULL) = 0
futex(0xb7678180, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0xb76782e0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(3,
"\200\0\0008Y\304\273\254\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3\0\0\0\0"...,
60) = 60
poll([{fd=3, events=POLLIN}], 1, 6) = 1 ([{fd=3, revents=POLLIN}])
read(3,
"\200\0\0\34Y\304\273\254\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3\371",
400) = 32
close(3)= 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
open("/etc/bindresvport.blacklist", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=367, ...}) = 0
read(4, "#\n# This file contains a list of"..., 1024) = 367
read(4, "", 1024) = 0
close(4)= 0
bind(3, {sa_family=AF_INET, sin_port=htons(604),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(1017),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
write(3,
"\200\0\0(m.M]\0\0\0\0\0\0\0\2\0\4\223\363\0\0\0\1\0\0\0\t\0\0\0\0"...,
44) = 44
poll([{fd=3, events=POLLIN}], 1, 4) = 1 ([{fd=3, revents=POLLIN}])
read(3, "", 4000) = 0
write(2, "amq: failed to get PID of amd\n", 30amq: failed to get PID of
amd
) = 30
exit_group(1) = ?
+++ exited with 1 +++
Having attached to a running amd process right before that amq invocation
this will then have resulted in the following report there:
# strace -f -p 4657
strace: Process 4657 attached
_newselect(1024, [3 4 5 6], NULL, NULL, {282, 847391}) = 1 (in [5], left
{281, 93032})
rt_sigprocmask(SIG_BLOCK, [HUP INT TERM CHLD], NULL, 8) = 0
gettimeofday({1475612569, 412383}, NULL) = 0
accept(5, {sa_family=AF_INET, sin_port=htons(604),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 7
dup(0) = 8
close(8)= 0
gettimeofday({1475612569, 412959}, NULL) = 0
gettimeofday({1475612569, 413030}, NULL) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
_newselect(1024, [3 4 5 6 7], NULL, NULL, {281, 0}) = 1 (in [7], left
{280, 999649})
rt_sigprocmask(SIG_BLOCK, [HUP INT TERM CHLD], NULL, 8) = 0
gettimeofday({1475612569, 413806}, NULL) = 0
poll([{fd=7, events=POLLIN}], 1, 35000) = 1 ([{fd=7, revents=POLLIN}])
read(7,
"\200\0\0(m.M]\0\0\0\0\0\0\0\2\0\4\223\363\0\0\0\1\0\0\0\t\0\0\0\0"...,
16384) = 44
open("/etc/hosts.allow", O_RDONLY) = 8
fstat64(8, {st_mode=S_IFREG|0644, st_size=707, ...}) = 0
read(8, "# /etc/hosts.allow: list of host"..., 1024) = 707
read(8, "", 1024) = 0
close(8)= 0
open("/etc/hosts.deny", O_RDONLY) = 8
fstat64(8, {st_mode=S_IFREG|0644, st_size=858, ...}) = 0
read(8, "# /etc/hosts.deny: list of hosts"..., 1024) = 858
close(8)= 0
time([1475612569]) = 1475612569
socket(AF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 8
connect(8, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = -1 ENOENT
(No suc
Bug#832650: systemd 230-7: boot fail panic abort due to wrong (outdated) Depends on libseccomp2, libidn11
:36:48 startup archives unpack 2016-07-28 07:36:54 upgrade libidn11:i386 1.32-3 1.32-3.1 2016-07-28 07:36:54 status triggers-pending libc-bin:i386 2.23-2 2016-07-28 07:36:55 status half-configured libidn11:i386 1.32-3 2016-07-28 07:36:55 status unpacked libidn11:i386 1.32-3 2016-07-28 07:36:55 status half-installed libidn11:i386 1.32-3 2016-07-28 07:36:55 status half-installed libidn11:i386 1.32-3 2016-07-28 07:36:55 status unpacked libidn11:i386 1.32-3.1 2016-07-28 07:36:55 status unpacked libidn11:i386 1.32-3.1 2016-07-28 07:36:55 trigproc libc-bin:i386 2.23-2 2016-07-28 07:36:55 status half-configured libc-bin:i386 2.23-2 2016-07-28 07:36:57 status installed libc-bin:i386 2.23-2 2016-07-28 07:36:58 startup packages configure 2016-07-28 07:36:58 configure libidn11:i386 1.32-3.1 2016-07-28 07:36:58 status triggers-pending libc-bin:i386 2.23-2 2016-07-28 07:36:58 status unpacked libidn11:i386 1.32-3.1 2016-07-28 07:36:58 status half-configured libidn11:i386 1.32-3.1 2016-07-28 07:36:58 status installed libidn11:i386 1.32-3.1 2016-07-28 07:36:58 trigproc libc-bin:i386 2.23-2 2016-07-28 07:36:58 status half-configured libc-bin:i386 2.23-2 2016-07-28 07:36:58 status installed libc-bin:i386 2.23-2 Thanks, Andreas Mohr
Bug#743955: coreutils: corrupted files on heavily fragmented ext3 and ext4 partitions
Hi, just wanted to ask: what is the status on this now sufficiently old issue? I keep hitting this via apt-listbugs reports when trying to upgrade from coreutils 8.13-3 to 8.23-4. However, note that the original report said "[bug introduced in coreutils-8.11]" (upstream version value, I assume) So, while I am currently upgrading, it looks like the issue actually already *is* present on my system since I'm *post* 8.11, thus the apt-listbugs warning is somewhat moot/useless here since I'm already past potentially hitting a regression. Thus, perhaps original attributes which were given as: Package: coreutils Version: 8.13-3.5 Severity: grave ought to be request-corrected to properly indicate an *earlier* Debian package version that already was affected (that way my apt-listbugs activity probably would not list this issue during upgrade of the versions that are relevant on my system, since there actually is no status change during this transition). But perhaps the more modern version value was intentionally specified in order to *do* always warn about this issue, even on systems which already upgraded to an affected coreutils version... And then, of course, there remains the question of whether the currently provided (upgrade target) version (8.23-4) already is one where this issue indeed is fixed. However since original report said "It is present in the wheezy coreutils version and is fixed in jessie/sid. A backport of the fix or an update of coreutils would be welcomed for wheezy." yet https://packages.debian.org/search?keywords=coreutils reports version in jessie as 8.23-4 which is exactly my upgrade target and which is a version which is said to be fixed, I'd come to think that this bug report is missing specification of some sort of "fixed-in" attribute. Hmm, but there's no "fixed-in" tag (since I assume the way to mark this is to simply and properly close a bug), but perhaps using "wheezy" (https://www.debian.org/Bugs/Developer#tags) would be the way to go? As it stands, I'm predominantly irritated by the fact that apt-listbugs somehow decides to keep reporting an issue which *is* said to be fixed in this very upgrade target version (and, to make matters much worse, this warning report may actively and strongly deter people from promoting an unhealthy system to a healthy state i.e. an actually fixed version!!!) [personally, I have now decided to proceed with the upgrade since it seems correct and important] Thanks, Andreas Mohr
Bug#728113: [smartmontools] Fails to run on a Wheezy/Jessie mixed system
Hi, I'm mildly confused about what the status/situation now is. Reason being that I just upgraded various packages *without* apt-listbugs yelling about a sufficiently grave situation of smartmontools, with the result of having a broken upgrade, which necessitated a (albeit simple) downgrade to fix things. I'm somewhat surprised that apt-listbugs did not yell (which would have been a good thing), but this might have been due to it possibly triggering for >= "grave", whereas this bug is currently (and possibly rightfully?) at "serious" rating (--> https://www.debian.org/Bugs/). So, given this bug's records/history I don't know easily which dependency exactly is causing issues here. I'm obviously not concerned about my local status - I can fix up things easily (I'm now pondering doing some modifications in the libc6 / libselinux1 area). I'd want to repeat the question asked initially, "All the dependencies seem to be satisfied. Maybe they are not stated correctly/strictly enough?". If there's any clarification that's available and worth stating, that would be great. Thanks a ton for your highly appreciated work, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622309: 167-3 works fine on EEEPC though
> Md> Try to rm -rf /run and reboot. > OK, thanks! I will try it on Monday. No you shouldn't. ;) mv /run /run.old_possibly_broken Otherwise you'd destroy a large amount of criminal evidence :) (and then perhaps run a diff -urN on the two directories, or some comparational debug invocation of rsync, or some such) Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#623961: xserver-xorg-input-evdev: X11 "mouse keys" / "plot mode" completely unusable post-Lenny, on 3 machines
Hi, On Sun, Apr 24, 2011 at 10:28:08PM +0200, Cyril Brulebois wrote: > Hi, > > Andreas Mohr (24/04/2011): > > Package: xserver-xorg-input-evdev > > Version: 1:2.3.2-6 > > Severity: grave > > Justification: use of entire desktop almost impossible, occurring on 3 > > quite different hardware environments > > why did you strip the bug script output? 'cause I had used the human script "variant" ;) > I'd suggest tracking it down on your sid machine, so that we can get > upstream feedback with failures reported against latest versions. See > the proposed backports policy[1], you could then enjoy a backported > fixed version at some point on your squeeze machine. Will do ASAP, as circumstances allow. Thanks for a very fast reply! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#623961: xserver-xorg-input-evdev: X11 "mouse keys" / "plot mode" completely unusable post-Lenny, on 3 machines
Package: xserver-xorg-input-evdev Version: 1:2.3.2-6 Severity: grave Justification: use of entire desktop almost impossible, occurring on 3 quite different hardware environments Hi, on one notebook where I had some rare intermittent touchpad failure I temporarily had to resort to "mouse keys" mode (see http://en.wikipedia.org/wiki/Mouse_keys ). However, I observed that it didn't work on that machine (Debian unstable), whereas on the machine that _now_ starts to have the same issue (MEPIS 11 - Debian Squeeze) it did work perfectly well. To clarify "didn't work": When enabling mouse keys via Alt-Shift-NumLock, I do get some cursor movement activity, however it's VERY erratic / distorted (cursor progresses in - also erraticely updated - steps of perhaps up to one inch each, i.e. even semi-precise navigation is impossible). Thus current behaviour is almost unusable compared to a previously fully working setup with nicely linearly updating mouse cursor. I managed to figure out that actual internal X11 cursor position _does_ get precisely updated, however: by Alt-Tabbing between some windows, one observes that the cursor does in fact properly make tiny jumps corresponding to previous minor mouse keys activity, but this unfortunately means that Alt-Tabbing is REQUIRED to make it do so properly (thus one would have to do a couple dozen Alt-Tabs to finally approach the precise cursor position to be able to Hit-Test a button rectangle _each time_). I had actually planned to submit a bug report about it previously already, and since I now hit the same issue on the third machine (where I never had a mouse connected) during upgrade, it's finally about damn time to do so ;) Machine 1 (Debian unstable): Notebook Dell Inspiron 8000, Rage Mobility M4 Machine 2 (upgraded to MEPIS 11): HP ePC, P3/1GHz, Intel i815 Machine 3 (Debian testing(?)): Athlon XP, also not working properly any more IIRC, Radeon (R100 or some such) I didn't find much information about this bug (X11 "mouse keys" are such damn fine search keywords, almost as good as"KVM"...), only a current report of "No more Xorg Mousekeys" https://bbs.archlinux.org/viewtopic.php?pid=904880 which is actually unrelated since I _do_ have (barely) working cursor activity, thus it is properly flag-enabled at least. Not sure whether the xserver-xorg-input-evdev component is the correct one to report it at, though (since the X11 server actually does record the correct cursor position, perhaps this would be more of a server-side or display-side component issue?). The pre-upgrade version of -input-evdev was 1:2.0.8-1 . At this upgrade: xserver-xorg-core: 2:1.4.2-10.lenny3 --> 2:1.7.7-13 xserver-xorg: 1:7.3+20 --> 1:7.5+8 As far as I am concerned, a rather important base feature of X11 is thus unusably broken. Is there any info yet, or ideas on current status and how to get it fixed? Thanks a lot for all your work, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570662: [PATCH] add missing include for ia64 and alpha
On Wed, Oct 13, 2010 at 11:06:51PM +0200, Serafeim Zanikolas wrote: > [please CC me on replies; I'm not subscribed] > > Hi, > > Here's a fix for Debian bug #570662 (FTBFS: error: '__NR_perf_event_open' > undeclared) #if defined(__ia64__) || defined(__alpha__) ;) And was that __NR_perf_event_open thing the one that I was having issues on MIPS? Hmm, need to verify... Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570662: powertop: FTBFS: error: '__NR_perf_event_open' undeclared
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570662 > # still fails on alpha and ia64: > # https://buildd.debian.org/status/package.php?p=powertop Confirmed, dito on Git MIPSEL (WL-500gPv2 OpenWrt 2.6.34.5 Debian stable extroot). Would have tried to fix it myself (patch --> upstream), but saw that Debian had some activity at #570662. Checked Debian source files, couldn't find all too much overly useful stuff (read: NONE). Bit wondering why buildd status page advertises mipsel as "installed", though, since Git did fail for me at __NR_perf_event_open. Config deviations?? Ping? Suitable CC's added. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593966: libc6: system-breaking (init OOPS) incompatibility with old prelink versions
Actually I'm not sure any more whether this is "a __severe__ problem for a branch-hopping minority(?) only": Boyd Stephen Smith Jr. realized that this might very well become a problem for "normal" branch upgrades from Lenny to Squeeze. If Squeeze libc6 upgrade processing happens before the upgrade of the prelink binary (and I think it does, since I believe libc6 upgrades happen rather early during an upgrade operation, before many other packages), we're ending up with the critical constellation during a normal upgrade as well. And since on a P3/500/512, a full Ubuntu upgrade I did once took >> 8 hours (possibly even longer with more modern installations), due to the slow performance there's a rather high chance to hit the cron.daily 24 hour processing's race window. Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593966: libc6: system-breaking (init OOPS) incompatibility with old prelink versions
Package: libc6
Version: 2.11.2-2
Severity: critical
Justification: breaks the whole system (repeatedly, in a timebomb manner)
Hi,
beginning of August my intention was to upgrade a system (AMD64 i386
stable; libc6-i686 installed additionally) to KDE 4.4.x.
I chose to do this by temporarily switching to testing repository.
All went more or less fine, except for suddenly ending up with all
shell binaries segfaulting. A reboot resulted in /sbin/init dying with
a nice kernel OOPS. Full stop.
Found #586241 (somewhat related issue), which recommended dpkg-deb:ing
over the libc6 / libc6-i686 libraries to restore the system. Worked.
Hurray.
Ultimately, I managed to figure out that the problem is caused by an old
prelink version which doesn't seem to get along at all with new(er?) libc6
version. See also the initial warning report,
"prelink-2007* and libc6-2.11* don't mix.":
http://lists.debian.org/debian-user/2010/06/msg02063.html
But, right after the upgrade, I hadn't realized the prelink issue
yet.
Note that, rather worse, prelink is cron-registered (cron.daily),
providing a nice time bomb by rendering a system fully unusable again the next
day.
IOW, you copy over pristine libc6 libs, everything boots fine again,
you think it's all fixed ("must have been some stupid libc6 update issue"),
and one day later it's all broken again right when one is unavailable
to get this fixed (yup, you're staring at the person that this happened to).
The issue occurred with the old prelink 0.0.20090311-1 package,
updating to 0.0.20090925-1 fixed everything, no more prelink breakage.
Contrary to the conclusion in the rather helpful warning given by Boyd Stephen
Smith Jr.
above (well, rather helpful if I actually had managed to find it in advance...),
I believe that something rather easy can and should actually be done about it,
to prevent other people from falling into the same very irritating trap:
provide a
Conflicts: prelink (<= 0.0.20090311-1)
package line or some such, which should hopefully be the proper means to
get this avoided.
I'm not sure of more precise version values to be provided here,
though, I only know of 0.0.20090311-1 behaviour.
libc6 specifics:
2010-07-31 19:11:57 upgrade libc6 2.9-25 2.11.2-2
Fallout of this issue really was not nice at all for me personally
(dead semi-production box for > 2 weeks, due to the cron timebomb complication),
thus myself I'd definitely want to see a protection applied,
despite being a __severe__ problem for a branch-hopping minority(?) only.
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568565: pm-suspend: rendered disabled by fatally broken locking implementation
Package: pm-utils Version: 1.2.6.1-3 Severity: grave Justification: most basic robustness principles violated, by a core system package AFAICS even a single unfortunate failure during suspend usage can render pm-suspend support terminally broken, with subsequent attempts always exiting immediately, without any logging to occur (not even when trying to get help by running pm-suspend --help or so) [I realize that hitting an occupied lock probably shouldn't get logged, though]. Possible failure leading to pm-suspend breakage includes - simple loss of power (notebook battery, wall socket) while suspended - a crash during suspend \ both rather common - a crash during resume/ behaviour, sadly The only way to trace failure is to run sh -x or define PM_SUSPEND, which then outputs: +++ return 0 +++ check_hibernate +++ '[' -n uswsusp ']' +++ SUSPEND_HYBRID_MODULE=uswsusp +++ '[' suspend = suspend_hybrid ']' ++ '[' -z uswsusp ']' ++ '[' -z uswsusp ']' ++ id -u + '[' 0 '!=' 0 ']' + try_lock pm-suspend.lock + mkdir -p /var/run/pm-utils/locks + local lock=/var/run/pm-utils/locks/pm-suspend.lock + return 1 + exit 1 /var/run/pm-utils/locks/pm-suspend.lock turns out to be about as old as my grandmother: -rw-r--r-- 1 root root 1 11-09 07:52 /var/run/pm-utils/locks/pm-suspend.lock Filing the report now to get things rolling, may continue investigation on how to fix the problem (possibly by checking age of lock and removing if older than 1 day or so). Note that there isn't any init script available either which might have removed a stale lock as one of its tasks... Since most users are likely to invoke pm-suspend via implementation-hiding frontends, they'll never know what hit them. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533897: reassigning to libx86
Hi, On Tue, Aug 04, 2009 at 02:19:56PM +0200, Michael Biebl wrote: > This definitely is a bug in libx86 and not uswsusp, so reassigning. > > FWIW, I can't reproduce the problem anymore with 1.1+ds1-4, so maybe this > issue > has already been dealt with. strings on libx86 1.1+ds1-4 does find "LRMI_base_addr", and pm-suspend does work, thus it seems fixed, can be closed, thanks! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
Hi, On Mon, Nov 17, 2008 at 11:44:04AM +0100, Martin Pitt wrote: > Martin Pitt [2008-11-16 16:59 +0100]: > > Upstream committed a different patch: > > > > http://www.cups.org/strfiles/3001/str3001.patch > > This patch is now included in 1.3.9-5, which just got uploaded to > experimental. Can you guys please test this version? If it works, I > need to push that to unstable and lenny, too, but the window for that > gets smaller every day. OK, I don't know what to make of this: I downgraded cups to 1.3.8-1lenny2 (the original, hanging version), tried printing two of the complex formerly problematic documents, didn't get any socket backend hangs this time (with printer "test" which remained configured exactly as last time when it did produce hangs). Verified timestamp of socket backend binary, was ok (October, matching distribution package, _NOT_ my custom-patched package version), and of course I had stopped and started cups, repeatedly even. Then I said "so what" and upgraded to incoming.debian.org 1.3.9-5 (plus _all_ cups helper packages), first submitted job got stuck at first page without producing any printer traffic, second job worked fine. (first job could possibly have been confused by an earlier Job Abort button action at the printer, though) Puzzled. Thanks a lot for your work, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
Hi, On Tue, Nov 11, 2008 at 07:40:40PM +0100, Samuel Thibault wrote: > Andreas Mohr, le Tue 11 Nov 2008 19:33:02 +0100, a écrit : > > Or, simply stated, how to disable the test suite to get a successful > > .deb package build? > > Usually you just need to prepend DEB_BUILD_OPTIONS=nocheck That did it. And re-attempting a 40-page duplexed job on cups Debian unstable 1.3.9-2 did hang just like before, and then downgrading to the patched 1.3.8-1lenny2 _does_ print immediately upon cupsd restart, without any socket backend lockup any more. Very nice work, thanks! > > Samuel Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
Hi, On Tue, Nov 11, 2008 at 02:46:55PM +0100, Samuel Thibault wrote: > Right but here the issue is on the input side: device_fd got to EOF, > thus select() returning it and read() on it returning 0. The attached > patch at least prevents select from returning, avoiding 100% CPU usage. Very nice, and fast reaction, too! I wanted to verify this patch to succeed versus the unpatched version to still fail with the very same test setup each, but I failed during package build (via fakeroot dpkg-buildpackage in the apt-get source'd cups-1.3.8/ directory): . . . lsb/usr/cups-included/Zebra/zebra.ppd Zebra ZPL Label Printer, 1.3 zebra.ppd Zebra ZPL Label Printer, 1.3 PASSED Test Summary PASS: Printer 'Test1' correctly produced 55 page(s). PASS: Printer 'Test2' correctly produced 23 page(s). PASS: 154 requests processed. PASS: 0 emergency messages. PASS: 0 alert messages. PASS: 0 critical messages. FAIL: 0 error messages, expected 9. PASS: 0 warning messages. PASS: 0 notice messages. PASS: 1 info messages. FAIL: 0 debug messages, expected more than 0. PASS: 0 debug2 messages. 2 tests failed. Log files can be found in /tmp/cups-root/log. A HTML report was created in /tmp/cups-root/cups-str-1.3-2008-11-11-root.html. Copies of the error_log and cups-str-1.3-2008-11-11-root.html files are in /usr/src/system/cups-1.3.8/test. make[1]: *** [check] Error 1 make[1]: Leaving directory `/usr/src/system/cups-1.3.8' make: *** [debian/stamp-makefile-check] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 birgit:/usr/src/system/cups-1.3.8# Or, simply stated, how to disable the test suite to get a successful .deb package build? (maybe I shouldn't ignore a failing test run though; then what?) Or could you tell me what the usual way is to do this cups .deb package build? Thanks a lot, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
OK, using HPLIP (hp backend, which appears to be recommended) submitting larger jobs seems to work without a backend lockup, however it's AWFULLY, almost unusably slow (1 page per 2 minutes or so, adding up to maybe 4 minutes per quadruple-duplexed PDF/PS page). (HPLIP is actually known to be very slow in certain configurations, too, and developers even already said that they're working on improving it) I don't know, but whichever thing I try to configure in CUPS, I'm _ALWAYS_ (yes, that's an always, since chances are about 60%) hitting a brick wall of some more or less severe sort (and I'm far from being the only one, judging from Internet discussions). IOW, I found a crude if acceptable workaround, thus severity should be left at grave, since the normal socket backend should at least be semi-usable, too. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
Environment clarification: HPLJ4000TN JetDirect J3111A Firmware G.08.49 (newest), on a BNC(!) connection. This being a 10Mbps BNC connection here could be another indication that this 100% CPU lockup issue possibly happens on slower connections only (this issue does not seem to be too wide-spread, thus maybe it affects slow-net users only) The CUPS backend mechanism had issues before already (STR #2664, http://www.cups.org/str.php?L2664+P0+S-2+C0+I0+E0+M20+Q ): r7204 | mike | 2008-01-09 19:59:55 +0100 (Mi, 09 Jan 2008) | 3 lines Don't select() on the output side of the device if we have a side-channel callback - this causes 100% CPU usage (STR #2664) Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495684: [965GM] no (Latin) characters and icons shown at login prompt and in the desktop
Hi, same here, no fonts visible on gdm login. Xorg.0.log showing EXA use, /proc/fb empty. 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) Subsystem: Hewlett-Packard Company Device 2802 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f040 (32-bit, non-prefetchable) [size=1M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at 1100 [size=8] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 2.6.26.2 (custom, make-kpkg): CONFIG_FB=y CONFIG_FB_DDC=m CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=m CONFIG_FB_SVGALIB=m # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_CIRRUS=m CONFIG_FB_PM2=m CONFIG_FB_PM2_FIFO_DISCONNECT=y CONFIG_FB_CYBER2000=m CONFIG_FB_ARC=m # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m # CONFIG_FB_UVESA is not set CONFIG_FB_VESA=y # CONFIG_FB_EFI is not set # CONFIG_FB_N411 is not set CONFIG_FB_HGA=m # CONFIG_FB_HGA_ACCEL is not set CONFIG_FB_S1D13XXX=m CONFIG_FB_NVIDIA=m # CONFIG_FB_NVIDIA_I2C is not set # CONFIG_FB_NVIDIA_DEBUG is not set CONFIG_FB_NVIDIA_BACKLIGHT=y # CONFIG_FB_RIVA is not set CONFIG_FB_LE80578=m CONFIG_FB_CARILLO_RANCH=m CONFIG_FB_INTEL=m # CONFIG_FB_INTEL_DEBUG is not set CONFIG_FB_INTEL_I2C=y CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y CONFIG_FB_MATROX_I2C=m CONFIG_FB_MATROX_MAVEN=m CONFIG_FB_MATROX_MULTIHEAD=y CONFIG_FB_RADEON=m CONFIG_FB_RADEON_I2C=y CONFIG_FB_RADEON_BACKLIGHT=y # CONFIG_FB_RADEON_DEBUG is not set CONFIG_FB_ATY128=m CONFIG_FB_ATY128_BACKLIGHT=y CONFIG_FB_ATY=m CONFIG_FB_ATY_CT=y # CONFIG_FB_ATY_GENERIC_LCD is not set CONFIG_FB_ATY_GX=y CONFIG_FB_ATY_BACKLIGHT=y CONFIG_FB_S3=m CONFIG_FB_SAVAGE=m # CONFIG_FB_SAVAGE_I2C is not set # CONFIG_FB_SAVAGE_ACCEL is not set CONFIG_FB_SIS=m CONFIG_FB_SIS_300=y CONFIG_FB_SIS_315=y CONFIG_FB_NEOMAGIC=m CONFIG_FB_KYRO=m CONFIG_FB_3DFX=m # CONFIG_FB_3DFX_ACCEL is not set CONFIG_FB_VOODOO1=m CONFIG_FB_VT8623=m CONFIG_FB_TRIDENT=m # CONFIG_FB_TRIDENT_ACCEL is not set CONFIG_FB_ARK=m CONFIG_FB_PM3=m # CONFIG_FB_GEODE is not set CONFIG_FB_SM501=m CONFIG_FB_VIRTUAL=m No *fb*.ko modules loaded. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393909: amd64: ttf-opensymbol package cannot be configured or removed
Hello, same here, on x86: fontconfig-2.3.2-7 was installed (I may have skipped a Debian point release still within 2.3.2!), got the following: # dpkg --configure -a Setting up ttf-opensymbol (2.0.4-2) ... Updating fontconfig cache... "/usr/share/fonts": error scanning "/usr/X11R6/lib/X11/fonts": error scanning "/usr/local/share/fonts": error scanning "/var/lib/defoma/fontconfig.d": error scanning dpkg: error processing ttf-opensymbol (--configure): subprocess post-installation script returned error exit status 4 dpkg: dependency problems prevent configuration of openoffice.org-core: openoffice.org-core depends on ttf-opensymbol; however: Package ttf-opensymbol is not configured yet. dpkg: error processing openoffice.org-core (--configure): dependency problems - leaving unconfigured ... [many other OOo chain reactions] ... Errors were encountered while processing: ttf-opensymbol openoffice.org-core openoffice.org-draw openoffice.org-gtk openoffice.org-calc openoffice.org-filter-so52 openoffice.org-kde openoffice.org-writer python-uno openoffice.org openoffice.org-help-en-us openoffice.org-gnome openoffice.org-thesaurus-en-us openoffice.org-gtk-gnome openoffice.org-impress openoffice.org-base openoffice.org-math openoffice.org-hyphenation-de openoffice.org-help-de Then during upgrade of fontconfig ttf-freefont fttools to resolve this I got: Preparing to replace fontconfig 2.3.2-7 (using .../fontconfig_2.4.1-2_i386.deb) ... Cleaning up font configuration of fontconfig... Cleaning up category cid.. Cleaning up category truetype.. Cleaning up category type1.. "/var/lib/defoma/fontconfig.d": error scanning "/var/lib/defoma/fontconfig.d": error scanning Unpacking replacement fontconfig ... Preparing to replace fttools 1.2-15 (using .../fttools_1.2-16_all.deb) ... Unpacking replacement fttools ... Preparing to replace ttf-freefont 20060501cvs-8 (using .../ttf-freefont_20060501cvs-9_all.deb) ... Unpacking replacement ttf-freefont ... Setting up ttf-opensymbol (2.0.4-2) ... Updating fontconfig cache... Setting up fontconfig (2.4.1-2) ... Updating font configuration of fontconfig... Cleaning up category cid.. Cleaning up category truetype.. Cleaning up category type1.. Updating category type1.. Updating category truetype.. Updating category cid.. Cleaning up old fontconfig caches... done. Regenerating fonts cache... done. Setting up openoffice.org-core (2.0.4-2) ... [all other OOo packages finally updated successfully] --verbose or strace as asked for in http://groups.google.de/group/linux.debian.bugs.dist/browse_frm/thread/79c819cbf1826c54/cabfe5ad7a41a2a3?lnk=st&q=%22error+scanning%22+debian+fontconfig&rnum=6#cabfe5ad7a41a2a3 didn't show anything unusual (access issues, ...). strace log still available on request. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337213: kdesktop: SEGV due to previous unstable -> testing transition, missing audio related dependency
Package: kdesktop Version: 4:3.4.2-4 Severity: grave Hello all, I found the new kde 3.4.2-4 testing packages in the archive yesterday, thus I upgraded my 3.4.2-3 unstable packages (installed maybe 4 weeks ago before I made the switch from unstable -> testing on this system). On next KDE startup, the result was a nice kdesktop crash (KDE error handler) with a backtrace that indicated audio related issues (sorry, didn't keep a copy of that backtrace), and of course kdesktop was gone. Since I strongly suspected audio package problems, I upgraded as many as I could find, from: Package: libaudio2 Version: 1.7-2 Package: libartsc0 Version: 1.4.2-4 Package: libarts1c2 Version: 1.4.2-4 Package: libaudiofile-dev Version: 0.2.6-3 Package: libaudiofile0 Version: 0.2.6-3 to: Package: libaudio2 Version: 1.7-3 Package: libartsc0 Version: 1.4.2-5 Package: libarts1c2 Version: 1.4.2-5 Package: libaudiofile-dev Version: 0.2.6-6 Package: libaudiofile0 Version: 0.2.6-6 I upgraded those and *only* those, and the crash was gone. IOW clearly a missing dependency issue (someone didn't expect me to upgrade an unstable KDE to a newer testing KDE version ;). Now if I knew which package exactly was causing this, then I'd be much wiser... (I guess you might want to look at some C++ ABI transition in one/some of these packages?) Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309591: pmount: DANGEROUS default settings (sync)
Indeed, "grave" may have been too high, but then the Severity description forgot to include the possibility of actually killing hardware, which should be rated rather high IMHO. I didn't know about the Sid tagging (Sid here, with a custom 2.6.11-ck8 kernel), sorry. The LKML thread indicates that FAT sync behaviour has been changed by Colin Leroy (http://readlist.com/lists/vger.kernel.org/linux-kernel/22/112590.html). The discussion thread for this patch is at http://www.ussg.iu.edu/hypermail/linux/kernel/0411.3/.html For the record, I'd like to publicly state here: - pmount should get rid of default sync ASAP for the moment, in order to avoid too many killed USB sticks - contrary to the strange belief of certain people: "we don't need a new sync mode", http://readlist.com/lists/vger.kernel.org/linux-kernel/22/112509.html) , I do think we want a special mount mode (if possible), to indicate that we want fast, but not ultra-immediate (sync) writeout of dirty buffers. The usual caching in async mode will take too long for people to notice that things aren't fully written yet (the USB flash LED will switch off again!), thus we need faster processing (almost constant writing without many dropouts would be desireable, yet not as crazy as updates on every single-byte change as with the sync flag). Plus, thinking of *manually* using "umount" or even something esoteric as "sync" is absolutely unthinkable for "less educated" (ahem) people who unplug things on a whim. Such a new mount flag could be called "nowritecache" or "nowritebuffer" to indicate that we don't want any write caching in the OS. But this is not a very accurate description of what we really want to have with USB sticks, so maybe "fastwrite" (preferred) or "instantwrite" or "immediatewrite" (hmm) are better. Thanks, Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309591: pmount: DANGEROUS default settings (sync)
Package: pmount Version: 0.8-1 Severity: grave Hi, apparently the sync option really should *NOT* be used, especially not by default: http://readlist.com/lists/vger.kernel.org/linux-kernel/22/111748.html Probably the best way is to get rid of the sync default in favour of an async default, and also make sure to warn against using sync on flash media in the man page (and README?) (eikke: JFYI) Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301670: rpc.mountd random port: devastating results, yet no precautions
Package: nfs-user-server Version: 2.2beta47-20 Severity: critical Hello, until yesterday I had nfs-server installed. This one contained rpc.mountd which according to man rpc.mountd chooses a random port number in case none is preconfigured. This had almost desastrous consequences upon the last bootup of my server: That time it decided to grab port 622, which is my reconfigured SSH port (some security measure, I wouldn't want to have standard port 22 open worldwide). Thus my ssh server (started AFTER the NFS server) detected that port 622 was in use, threw its arms into the air in despair, withered and died. In other words, this random port selection (in the pre-1024 range?) may KILL REMOTE ACCESS TO AN ENTIRE BOX! I was a very lucky bastard who still had telnetd installed for access from the local net to my headless server, so I was able to figure out the problem after some very puzzled minutes. I assume that the rpc.mountd contained in the current nfs-user-server package has the same behaviour, i.e. choosing random ports if no port is preconfigured (the same "random port" notice is mentioned in the man page of this version, and a first netstat -a test seems to confirm it, with ports 633 and 820 chosen). Given the severity of this problem, adding a very visible note to the package description (dpkg -s) or choosing a preconfigured port in the default package configuration (better?) would probably be a very good thing to do. I was unsure which Severity to choose for that (http://www.debian.org/Bugs/Developer#severities), but given that it may kill important services if it gets started on the same port as those before those get started, I rated it as "critical" (which is very high, admittedly, breaking Debian release processing). Feel free to rate it down if you think it is less severe, but it can kill access to the whole box after all (and it does break "unrelated software", as listed in the very definition of the "critical" severity, and even randomly, so it's not even predictable which service will fail on next bootup or runlevel change). Thank you, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
