Bug#803016: libxml2: Upgrade fails with "triggers ci file contains unknown directive `activate-noawait'"
Package: libxml2 Version: 2.7.8.dfsg-2+squeeze13 Severity: important This console output probably says it all: $ sudo apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: libxml2 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/813 kB of archives. After this operation, 241 kB of additional disk space will be used. Do you want to continue [Y/n]? y (Reading database ... 33143 files and directories currently installed.) Preparing to replace libxml2 2.7.8.dfsg-2+squeeze12 (using .../libxml2_2.7.8.dfsg-2+squeeze13_i386.deb) ... dpkg: error processing /var/cache/apt/archives/libxml2_2.7.8.dfsg-2+squeeze13_i386.deb (--unpack): triggers ci file contains unknown directive `activate-noawait' configured to not write apport reports Errors were encountered while processing: /var/cache/apt/archives/libxml2_2.7.8.dfsg-2+squeeze13_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: 6.0.10 APT prefers squeeze-lts APT policy: (500, 'squeeze-lts'), (500, 'oldoldstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-xen-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libxml2 depends on: ii libc6 2.11.3-4+deb6u7 Embedded GNU C Library: Shared lib ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages libxml2 recommends: pn xml-core (no description available) libxml2 suggests no packages. -- no debconf information
Bug#755771: keepalived: Should not depend on ipvsadm
Package: keepalived Version: 1:1.2.13-1 keepalived currently declares a hard dependency on ipvsadm. It should not, as keepalived may very well be used for VRRP instead. A Recommends or Suggests would be more appropriate. Tore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734004: Works with latest upstream
This is now available upstream: https://git.gnome.org/browse/network-manager-openvpn/commit/?id=77115c5377e009220c3c98102450f92d3a7f6f9e FWIW, Fedora has pushed a prerelease (git snapshot) to their stable repositories as NetworkManager-openvpn-0.9.9.0-0.1.git20140128. Maybe Debian could follow suit? Tore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#468801: libc6: RFC3484 scoping rules should only affect IPv6, not IPv4
* Marco d'Itri Agreed. Can the libc maintainers please comment on this issue? The next Debian release will be used in a period in which more and more sites will deploy IPv6 and we must be sure to not make them less reliable for the people adopting transition mechanisms. Just adding some information here - I've asked a number of other distributors, and currently Debian is the only one that has not yet applied the patch to its developement branch (or stated an intention to do so). See: https://bugzilla.redhat.com/show_bug.cgi?id=577626 https://bugs.launchpad.net/glibc/+bug/555210 http://bugs.gentoo.org/show_bug.cgi?id=315977 https://bugzilla.novell.com/show_bug.cgi?id=597616 https://qa.mandriva.com/show_bug.cgi?id=58834 Best regards, -- Tore Anderson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#468801: libc6: RFC3484 scoping rules should only affect IPv6, not IPv4
Hi, another update here: Ubuntu has also applied the patch to their libc package, see https://bugs.launchpad.net/555210, and it will as I understand it be part of their release that's due in a couple of weeks. It would be great if Debian could also apply the patch. That is clearly the behaviour that will serve end users the best. Best regards, -- Tore Anderson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#468801: libc6: RFC3484 scoping rules should only affect IPv6, not IPv4
Just a little update here: Fedora has commited the change and it'll be
part of F13. See https://bugzilla.redhat.com/show_bug.cgi?id=577626. I
have tested their patch (attached) and it works as expected.
It would really be fantastic if this could be commited to Debian as well!
Best regards,
--
Tore Anderson
--- glibc-2.11-332-g2e7c805/ChangeLog
+++ glibc-2.11.90-17/ChangeLog
@@ -1,3 +1,9 @@
+2010-04-06 Ulrich Drepper drep...@redhat.com
+
+ * sysdeps/posix/getaddrinfo.c (default_scopes): Assign global
+ scope to RFC 1918 addresses.
+ * posix/gai.conf: Document difference from RFC 3484.
+
2010-04-05 Thomas Schwinge tho...@schwinge.name
* sysdeps/gnu/unwind-resume.c: New, moved from nptl/sysdeps/pthread/.
--- glibc-2.11-332-g2e7c805/posix/gai.conf
+++ glibc-2.11.90-17/posix/gai.conf
@@ -41,7 +41,7 @@
#
# precedence mask value
#Add another rule to the RFC 3484 precedence table. See section 2.1
-#and 10.3 in RFC 3484. The default is:
+#and 10.3 in RFC 3484. The RFC requires:
#
#precedence ::1/128 50
#precedence ::/0 40
@@ -58,7 +58,7 @@
#Add another rule to the RFC 3484 scope table for IPv4 addresses.
#By default the scope IDs described in section 3.2 in RFC 3484 are
#used. Changing these defaults should hardly ever be necessary.
-#The defaults are equivalent to:
+#The definitions in RFC 1918 are equivalent to:
#
#scopev4 :::169.254.0.0/112 2
#scopev4 :::127.0.0.0/1042
@@ -75,3 +75,5 @@
#scopev4 :::169.254.0.0/112 2
#scopev4 :::127.0.0.0/1042
#scopev4 :::0.0.0.0/96 14
+#
+#This is what the Red Hat setting currently uses.
--- glibc-2.11-332-g2e7c805/sysdeps/posix/getaddrinfo.c
+++ glibc-2.11.90-17/sysdeps/posix/getaddrinfo.c
@@ -1099,10 +1099,12 @@ static const struct scopeentry
/* Link-local addresses: scope 2. */
{ { { 169, 254, 0, 0 } }, htonl_c (0x), 2 },
{ { { 127, 0, 0, 0 } }, htonl_c (0xff00), 2 },
+#if 0
/* Site-local addresses: scope 5. */
{ { { 10, 0, 0, 0 } }, htonl_c (0xff00), 5 },
{ { { 172, 16, 0, 0 } }, htonl_c (0xfff0), 5 },
{ { { 192, 168, 0, 0 } }, htonl_c (0x), 5 },
+#endif
/* Default: scope 14. */
{ { { 0, 0, 0, 0 } }, htonl_c (0x), 14 }
};
Bug#468801: libc6: RFC3484 scoping rules should only affect IPv6, not IPv4
Hi, The current practise of scoping RFC 3484-addresses as site-local is causing real operational problems on today's internet, and is inhibiting the rollout of IPv6 on the content side: Consider a setup where an end user has his computer on a LAN with RFC 1918-based private IPv4 addresses (using NAT to connect to the global internet), as well as 6to4-based IPv6 addresses (or could be Teredo for that matter). In this case, when a web server is dual-stacked, getaddrinfo() will sort the 6to4-based IPv6 connectivity above the NAT-based IPv4 one. Transitional IPv6 tunneling like 6to4 is inherently less reliable than the IPv4 connectivity it runs on top of, so if the user has non-working transitional IPv6 connectivity (quite common), he will experience a dual-stacked web site as being simply down, or extremely slow (as all connection attempts over IPv6 needs to time out before the browser falls back to IPv4). Since web site operators are usually interested in having as many visitors as possible, the prospect of actually making the site unavailable for a not insignificant amount of users are keeping them from deploying IPv6 altogether. Rémi has documented the problem in detail here: http://tools.ietf.org/html/draft-denis-v6ops-nat-addrsel-00 There's currently a draft out that aims to correct this shortcoming (amongst others) in the original RFC: http://tools.ietf.org/html/draft-arifumi-6man-rfc3484-revise-02 Quote: 2.7. To change private IPv4 address scope As detailed in Remi's draft [I-D.denis-v6ops-nat-addrsel], when a host is in NATed site, and has a private IPv4 address and transitional addresses like 6to4 and Teredo, the host chooses transitional IPv6 address to access most of the dual-stack servers. This is because private IPv4 address is defined to be site-local scope, and as in RFC 3484, the scope matching rules (Rule 2) set lower priority for private IPv4 address. By changing the address scope of private IPv4 address to global, this problem can be solved. It's worth nothing that FreeBSD and Microsoft appears to already have changed their getaddrinfo() implementations accordingly. Considering that the original RFC was written by Microsoft to begin with, this is in my opinion a clear admission that this is a shortcoming of the RFC. I have submitted a bug about the problem to the upstream glibc maintainers: http://sourceware.org/bugzilla/show_bug.cgi?id=11438 The feedback I got was basically that while he agrees there is a real problem here, he is reluctant to make the upstream change until the standardisation process is finished. However, he goes on to suggest that the distributors should work around the problem locally in the meanwhile. Because this bug is causing real operational problems that are holding back the IPv6 rollout, and with less then a year's worth of IPv4 addresses left in the IANA pool (cf. http://ipv4depletion.com/), it is really starting to become urgent to get these operational issues fixed ASAP. I therefore hope that Debian can help out by implementing the suggested change, either by shipping the /etc/gai.conf file by default, or by modifying the getaddrinfo.c sources, so that RFC 1918-based addresses are treated as globally scoped by default. Best regards, -- Tore Anderson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#456640: status of munin ITA
* Holger Levsen Matthias and me still plan to upload munin 1.2.6 RSN now ;) Yay! :-) Thanks for taking over the package from me guys, it really needed someone with a bit more time to care for it.. Tore, can you arrange that for Thijs, please? Certainly; I've now sent him the login credentials directly in a separate email. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456640: munin comaintaince
* Matthias Schmitz Since this is my first maintainership it is a good idea to have some more experienced co-maintainers. And if linpro has nothing against it i will keep the code in the upstream svn. Nothing against that at all, in fact I see it as a big advantage. Much easier to branch and merge stuff from upstream releases and so on. I'll make SVN users for Holger and Bernd, then. Any preferred usernames or just first names? -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456640: munin comaintaince
* Holger Levsen today I stumbled upon #403341, which has a very simple fix. There are quite some similar bugs (simple, with patch) in the debian BTS which I would like to help fixing, as I use munin heavily for work, in Debian Edu and privatly. So I like to request access to the upstream SVN, as this is where the debian packaging is kept, AIUI. Jose (as new owner of this bug), what do you think? I cc:ed Bernd, as we spoke about team maintaining munin in December last year.. Also, I would suggest to build the munin-plugins-contrib per default and upload it to Debian, so that these plugins are available even more easily. Of course there should be a prominent reminder that those plugins are not part of munin upstream. Then I would also suggest to include plugins to monitor vservers and xen instances. Hi guys, glad there's finally some interest in taking over the package from me. I think there's at least a year since I've had any free time and motivation to work on Debian packaging, so it's about high time somebody takes care of it again... Matthias Schmitz was the first one to contact me about taking over the package, and he's been actively following up on that by taking on lots of outstanding work on the 1.2.x branch. My colleague Stig Sandbeck Mathisen has also been trying to work his way through the huge backlog of bug reports (sorry about those). I am under the impression that their work will likely result in a new upstream release (1.2.6) as well as new Debian packages. So I intend to give the package to Matthias, and leave it up to him to decide how he wants to arrange the maintanership, that is, if he wants co-maintainers, if he still wants to keep the code in the upstream SVN repo, and so on. So you should all talk to him. :-) I never heard anything from Jose Carlos Medeiros about taking over the package, by the way. BTW. We have an IRC channel, [EMAIL PROTECTED] Matthias, Stig, and me hangs out there. Feel free to stop by. :-) Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456640: munin comaintaince
* Holger Levsen Cool. Currently I'm actually mostly interested in bringing 1.2.x in (even better) shape, as this is what I use. But then, I'm happy to switch to 1.3 if upstream thinks it's ready. (Which I dont believe it is, considering it's not even in experimental.) 1.2.6 will be part of 1.2.x. ;-) Is this OFTC or freenode or really another irc network? Neither, it's just our (Linpro's) stand-alone interal IRC server. Maybe it's time to move the channel elsewhere now that Munin isn't really a Linpro-only project any longer, but that's not up to me to decide. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456640: RFA: munin -- network-wide graphing framework (grapher/gatherer)
Package: wnpp Severity: normal I don't have time to maintain the Munin packages any more (and haven't for quite a while either, truth to be told). So there's a bunch of bugs reports that hasn't yet been looked at, and although the packages themselves are in quite good condition there's lots of reports of upstream bugs that needs to be triaged and fixed/forwarded. The packages are currently maintained in the upstream SVN repository, and the new maintainer(s) will be given write access there. The 1.2 stable branch is de-facto maintained by the Debian maintainer at the moment, so you'll be free (or even encouraged) to make new upstream releases instead of carrying patches in the Debian diff. The new major upstream release is still under developement, but it's still some months away I believe. The package description is: Munin is a highly flexible and powerful solution used to create graphs of virtually everything imaginable throughout your network, while still maintaining a rattling ease of installation and configuration. . This package contains the grapher/gatherer. You will only need one instance of it in your network. It will periodically poll all the nodes in your network it's aware of for data, which it in turn will use to create graphs and HTML pages, suitable for viewing with your graphical web browser of choice. . It is also able to alert you if any value is outside of a preset boundary, useful if you want to be alerted if a filesystem is about to grow full, for instance. You can do this by making Munin run an arbitrary command when you need to be alert it, or make use of the intrinsic Nagios support. . Munin is written in Perl, and relies heavily on Tobi Oetiker's excellent RRDtool. To see a real example of Munin in action, you can follow a link from http://munin.projects.linpro.no/ to a live installation. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-k7 Locale: LANG=nn_NO.UTF-8, LC_CTYPE=nn_NO.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443805: O: xfonts-ay
Package: wnpp Severity: normal Description: Audun Ytterdal's ANSI-fonts with Scandinavian characters This package contains some nice fixed-width fonts created by Audun Ytterdal. Most of them come in special versions as well as the normal one; one for Norwegians and Danes (no), one for Swedes (se), and one which combines the two (all). . To get the accented characters in the special versions, some other rarely used characters are sacrificed. The fonts included are: . - shine (Norwegian+Danish, Swedish, combined, and normal versions) - outcast (Norwegian+Danish, Swedish, combined, and normal versions) - bright (Norwegian+Danish, Swedish, and normal versions) - zaber (Norwegian+Danish and normal versions) - peq (Norwegian+Danish, Swedish, combined, and normal versions) - peq2 (normal version only) - zone (normal version only) -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-k7 Locale: LANG=nn_NO.UTF-8, LC_CTYPE=nn_NO.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435934: munin should suggest libwww-perl, needed by the apache_volume plugin
close 435934 quit * phil Munin's apache_volume plugin needs the LWP::UserAgent perl module, which is provided by Debian's libwww-perl package. I therefore suggest that munin should suggest or recommend (or maybe require) libwww-perl. It does, but you're looking at the wrong package. The apache_volume plugin is contained in the package called munin-node, which has suggested libwww-perl for ages. I'm closing this bug. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379138: fails to start if there's labeled addresses present
* Andrew Pollock For what it's worth, if I add an IP address to eth0 with a label of eth0foo, ifconfig also has a hard time dealing with the situation. Try it and see. I suspect iproute is letting us doing things with the networking that older tools and methods of querying can't deal with. Well, ifconfig has been deprecated for years in favour of iproute2, precisely because it can't deal with lots of functionality modern Linux kernels provide. Developement on net-tools ceased in April 2001! So that's not really a good excuse for the dhcp3 suite to failing to work in what has been a perfectly valid setup for many years, IMHO. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419948: munin: stark cpu increase sarge-etch
reassign 419948 librrds-perl quit * Florian Schlichting downgrading librrds-perl to oldstable indeed brings CPU back to pre-etch levels. Interestingly, this doesn't just pertain to nice cycles, but also more than halves system cycles. Okay, in that case there's nothing I can do really. Reassigning to librrds-perl. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419948: munin: stark cpu increase sarge-etch
* Florian Schlichting updating a stable server from sarge to etch, the amount of CPU munin uses presumably for graphing has increased 4- or 5-fold. Please see attached graph (I nice'd the cronjob, all other services run with normal priority). While we all know that new software always needs more resources, I think this is a bit gross, especially given that it's the same amount of graphs that look absolutely the same. I realize that the actual graphing is not done by munin, but I'm not sure exactly where all these CPU cycles are spent, so please reassign if appropriate. It is done by RRDtool. Could you try downgrading librrds-perl to the Sarge version, or trying to nice only the munin-graph subprocess, to make sure it's the graphing that eats resources? Edit /usr/bin/munin-cron to do that. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416098: kills my server on install
reassign 416098 linux-image-2.6.18-4-amd64 retitle 416098 MegaRAID SAS adapter locks up quit * Steinar H. Gunderson I'm unsure if this is a munin bug or a kernel bug; I'm filing against munin, but it should perhaps be reassigned. I installed munin on a Dell PowerEdge 2950: Setting up munin-node (1.2.5-1) ... Initializing plugins.. At this point, ssh froze. I connected through the remote admin console, which was filled with messages like: megasas: [65] waiting for 140 requests to complete megasas: [70] waiting for 140 commands to complete megasas: [75] waiting for 140 commands to complete megasas: [80] waiting for 140 commands to complete I googled this error message and it seems a lot of people have seen lockups with this SAS adapter (without there being any mention of Munin). Unless you can reproduce this I agree with Stephen that the kernel (or hardware) is at the prime suspect, and that it happened during a Munin installation was just random chance. Therefore I'm reassigning the bug. To repeat the step the init script did at the time of the crash, you run the following command: munin-node-configure --shell --debug | sh -x That does the same, but with more debug information. The server never recovered, and I had to (remote) reset it. In other words, some plugin in munin-node kills the megasas driver, which in turn kills the entire server. Well, I'm not aware of any plugins that could possibly do this. The only plugins I know that are run with elevated privileges and that have something to do with block devices is smart_ and hddtemp_smartctl, but they both rely on the helper program smartctl so the bug has would have had to be in that program anyway. * Stephen Gran Disclaimer: I am not a munin maintainer. Would you like to be? :-) I really need a comaintainer or for someone to take over the package completely - way too little free time these days. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#242394: [radeon] Initializes only once after boot
close 242394 quit * Brice Goglin About 3 years ago, you reported a bug to the Debian BTS regarding a radeon board only initializing after boot. Did you reproduce this problem recently? If not, I will close this bug in the next weeks. No problem. I don't have the hardware required any longer. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
* Peter Eisentraut Well, I don't know what Ubuntu has done or does, but the current behavior was requested in Debian bug reports. If we don't run ntpdate on ifup, when would we run it? During boot, after the network is normally started, and before system services are started. If there's no network available before services are started, the clock should not be stepped by ntpdate at all. IMHO. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
* Peter Eisentraut The ntpdate README.Debian says: ntpdate is run whenever a network interface is brought up. To adjust this behavior, the file /etc/network/if-up.d/ntpdate should be edited. That file in turn says: # ... Feel free to change this, especially if you regularly # bring up new network interfaces. If people don't read the documentation, we can't help them. Why would you expect me to read the documentation of the ntpdate program when it is a completely unrelated command, ifup, that I am running? To look at it the opposite way, if I wanted to adjust my clock, I would go read the NTP documentation, not the networking documentation. And I would certainly not expect the ntpdate invocation to result in an ifup being run. That said, the ntpdate default configuration is optimized for a desktop. On a server you would use ntpd anyway, so there is no need for ntpdate. I think this is a reasonable compromise. I agree, but on Ubuntu ntpdate is part of the default server installation (the meta package ubuntu-minimal depends on it, and it's priority important). It is more exusable to mimic their behaviour in Debian if the ntpdate program isn't installed by default. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
* Scott James Remnant I'd actually argue that you wouldn't want to forcibly change the clock once the first service is *starting*. As soon as you have at least one service running, it's arguably dangerous to slew the clock, and instead we should always step it from there on. Say what?! I hope you've just mixed up the terms here... slew - adjtime() - safe, clock will never leap step - settimeofday() - unsafe, clock will leap [back in time] I'll read the rest of your email assuming you exchanged those two. If ntpdate is lucky enough to get run before the first service is starting, there's no real harm in slewing it. Yes. That is exactly the role of the ntpdate program. Get the clock into a reasonably correct state before services have begun starting, and ntpd will take it from there and keep it in sync. Without the initial ntpdate call you risk that ntpd will step after five minutes of uptime, because ntpd won't do anything at all before it has finished electing a syspeer and so on, and that takes a few minutes. In those minutes a lot of services have probably have started, and when ntpd finally realises it wants to step, and does, Bad Things might happen. Therefore I want both ntpdate and ntpd in a server. The trick is weighing up the odds; if it's slewed, it can harm servers; but if it's stepped, desktop users will complain that their clock is wrong on boot, and takes a long time to get itself right again. Our primary reason for running it at all is dealing with desktops/laptops with broken hardware clocks. Servers will almost certainly be running ntpd if they care about the time. [...] I believe there's a fair amount of resistance to running ntpd in our default installation. What I installed was a server install. I got certainly got ntpdate with the ifup script (can't quite remember if ntpd was there after the install, but I guess not based on what you're writing above). I also agree servers are best served by ntpd, so it is strange to hear there's resistance against including it in the default installation..? Also ntpdate's documentation states pretty clearly it is no replacement for ntpd at all. Desktops are another matter. I care most about the servers, as I've got probably two or three hundred times as many of those than I do desktops, so I know much less about desktops and what the desktop users in general want. :-) That said, I don't think the always step policy you have (i.e. ntpdate -b) is good there either. If you run ntpdate without any arguments it will step, but only if the offset is 128ms. According to its documentation, anyway. Will really a user complain about the clock being wrong when it's way less then a second wrong? (Actually, I see now that the manual page is self-contradictory, it states elsewhere that the step treshold is 0.5 seconds. But I would think that's insignificant anyway.) We think it's a bug in our current install; but one that is less than the previous bug of the clock being not changed at all. Debian certainly shouldn't follow suit, unless they're also happy to have an open bug that the clock is slewed whenever a network interface comes up. I actually submitted a bug to Launchpad about this and had it closed because it was allegedly fixed in the latest release. I didn't verify that myself, though... Maybe I should. I didn't find an open bug about it either. Do you have a link? The udev daemon being started doesn't have any bearing on whether a network interface is up or not; network interfaces come up at their own leisure. It should be run after udev because I would assume it is useless to even attempt it before. If it still was unable to sync the time because it had no connectivity to the NTP server, well, it failed the one shot it did have and that's that. I see no harm in attempting to run ntpdate just as we're switching to the multiuser runlevel, there's nothing to lose from failure and plenty to gain from success. Our plan for feisty is to run ntpdate as an upstart job (an init script in SysV terms), the state in which it can be run defined as a point after a network interface has come up, but before the boot sequence has finished. If someone needs a clock syncing afterwards, we can either require ntpd; or use -B. This sounds very good to me, it would certainly take ntpdate off my blacklist. :-) Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
* Peter Eisentraut You are expected to read the README.Debian file of every package you install. Right. You have way too much faith in our users, including me. I don't know what Ubuntu has to do with this. You should try reading the whole bug report, then. I would expect you to have no problem with it, if you've read all those README.Debian files... :-P This bug is about copying Ubuntu's current behaviour, which is to run ntpdate on every ifup. The text I initially replied to was from Ingo Oeser: The proposed solution of using /etc/networking/if-up.d/ works without any problem for most of your users. Actually unbuntu Dapper Drake is just doing it this way and I never had any problems. We fixed it for our customers the same way. I said the way Ubuntu does it is unsafe and that it causes major problems if you're unlucky like me. Scott James Remnant of Ubuntu has acknowledged this, too: We think it's a bug in our current install; but one that is less than the previous bug of the clock being not changed at all. Debian certainly shouldn't follow suit, unless they're also happy to have an open bug that the clock is slewed whenever a network interface comes up. (I'm fairly sure he meant stepped instead of slewed here, btw.) But he pretty much sums up what I'm trying to advocate here. I'm interested in Debian and Ubuntu being as excellent operating systems as possible, and I feel this behaviour run counter to that, at least when they're used on servers where you really really don't want magic things like this to happen. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
* Scott James Remnant Matt's asked me to jump in here to explain the Ubuntu changes, and our long-term plan for such thing; as there seems to be a little confusion and/or argument on this topic. Thanks, I appreciate it. Our reason for moving this to an if-up.d script is because we're increasingly relying on udev to drive the hardware parts of our boot sequence; this meant that there was no point in the SysV boot sequence where networking was up, so no point to run the ntpdate script. Moving to an if-up.d script meant that the clock would be adjusted during boot when the each ethernet card came up; the first not being sufficient as that one might not actually get an IP. I know, but see below for comments. This isn't ideal either, as now ntpdate gets run every time you fiddle with an interface. Our preferred solution is to use upstart to manage the ntpdate task, and don't run it once it has succeeded at least once. I'm not familiar with upstart, I'm afraid, so I can't comment on that. We use -b because it was what was suggested in the manual page: -b Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time. The if-up.d ntpdate script is intended to set the clock at boot time, once the first interface with a reachable ntp server has come up. But right now it does not check if any of this is true, which is my main grief here. When the services are done being started (and I think you'll have to assume they do during bootup), it is not safe to step the clock. I think it would be reasonable to assume that this is a concern primarily for server systems that are probably always connected anyway, and thus it would be okay to step the clock later if there was no network at boot (even though this can cause trouble for desktop systems too in some cases, see #364288 for an example). In any case, though, it should not be stepped unless deemed necessary by ntpd[ate] because of a large offset. So if there's a chance of ntpdate being run after bootup, it shouldn't use -b. Default behaviour is okay. I've cooled down a bit now, so I'll moderate myself a bit about demanding -B. :-) * Tore Anderson If no NTP server is available at bootup, well, then you'll just have to wait for a network connection and possibly step the time then. * Scott James Remnant That's what we're trying to do with the ntpdate script. My opinion is that ntpd is better used for this. When I run ntpd, I expect it to do so if necessary. When I run ifup I expect it to do just that - bring an interface up. Not meddle around with system time, or do any other things unrelated to bringing the interface up. I'm a sysadmin. I don't like surprises. Having my clock stepped on ifup is definetively a surprise, and a nasty one too (offlined half our office). Besides, using ntpd for this would handle the situation where a route to the NTP server is provided by something else than ifupdown, such as a routing service (my case), a PPP[oE] daemon (common xDSL/GSM setups here in Norway at least), and probably other situations too. Finally, ntpd is more accurate than ntpdate - at least it says so in the manual page. Given the above, how would you recommend we sync the clock during boot if no clock adjustments would be preferred? Note gratuitous. I realise that's a matter of personal opinion, but I agree both with you and ntpdate's manual page that stepping on bootup is fine. On the other hand, I think stepping at an arbitrary time after the system is up and running is just asking for trouble, at least for production systems (and again, it might be for desktops too). If I understand you correctly you/Ubuntu think this is an acceptable trade- off and I obviously disagree with you on that. So my recommendation would be to call ntpdate on bootup after udev was started (maybe using Required-Start: $network instead if that's working). If it failed, oh well, start ntpd -g anyway and it'll synchronise when/if the time server becomes reachable at some later point. And most importantly - it will not step unless it feels it needs to do so because of a large offset, and paranoid me, running services I know depend on clock sanity, can add -x to the the ntp- server init script and be safe no stepping will occur after initial boot. If you insist on coupling this to ifup, though: Check to see if the ifup is related to time server reachability at all (in my case it wasn't, which made the whole ordeal feel even more pointless). In pre-up.d do ip route get time server, see if there's already a route there, and if so just skip syncing (or at least, drop -b) in post-up.d. Also you could make the script see if /etc/nologin is present, if not, it's likely not running at system bootup, skip
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
* Kurt Roeckx -b means always step, -B means slew, and you asked for -B before? Ranked in order of preference (as defaults, at least): 1) No gratuitous clock adjustments whatsoever (no if-up.d script) 2) No gratuitous clock stepping whatsoever (use of -B) 3) No gratituous clock stepping unless large offset (default ntpdate) 4) Gratituous clock stepping (use of -b) Ubuntu went with #4 for their Dapper release. It now seems to be using -b if it's a static interfacce. Do you mean a interface not using DHCP here? If so I wonder what that has got to with anything... ntpdate shouldn't be changing time when ntpd is running, and ntp doesn't get restrarted by default, so I guess I'm still not getting it. If the scripts turns into a no-op when ntpd is installed I have no objection to it (although I really think -b isn't called for in any case). That didn't happen in Ubuntu though... All I'm asking is that if you implement something similar in Debian, please be more careful then they were. Clock stepping is _dangerous_ and should IMO be done only as the system is brought up, and especially not as a result of fiddling with something that one would think is completely unrelated to system time, such as network interfaces. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402359: munin-node: smart_ plugin is buggy
close 402359 1.2.5-1 quit * Gabriele Vivinetto It does not correctly handle smartctl return code. This is fixed in munin 1.2.5. Please backport. I am sorry, that's not possible. The only fixes that'll make it into Sarge is for very grave problems, and I am certain this one does not qualify. Therefore I am closing the bug. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
* Ingo Oeser The proposed solution of using /etc/networking/if-up.d/ works without any problem for most of your users. Actually unbuntu Dapper Drake is just doing it this way and I never had any problems. We fixed it for our customers the same way. This is scary. I just had a rather unpleasant experience with this behaviour on a router box here. Time was a little bit out of sync, upped an interface, and then the time was stepped, something that made OSPF die in horror as it can't quite cope with the situation where time goes backwards (no wonder). So the if-up.d call need to use the -B option orelse it's not safe to have this package installed on production systems. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
* Kurt Roeckx Can I suggest you run ntpd with the -x option in that case? I already do. Both ntpdate and ntpd will by default slew the time if it's smaller the 128 ms, and step when it's bigger. I know. Maybe I should have been clearer though, what I'm objecting to is primarily the suggestion to mimic the way Ubuntu does it, as they invoke ntpdate with the -b parameter in the if-up.d script, ensuring that the clock will _always_ leap. I also have an objection to the if-up.d script per se, though, but this is not as strong. I simply do not expect things to happen to my clock when I fiddle around with my network interfaces. I have always thought the primary task of ntpdate is to quickly get time roughly correct at bootup, so that ntpd will have a much easier job of getting the box completely into sync. When this combo is working ntpd will ~never step time, even without -x (barring bad hardware). If no NTP server is available at bootup, well, then you'll just have to wait for a network connection and possibly step the time then. And isn't that _exactly_ what ntpd'll do when run without the -x option? Then why throw ntpdate into the mix here? It's after all less precise than ntpd so chances are you'll end up with a clock that's more out of sync than before... -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401910: munin-node: apt cron job runs even when apt plugin is not enabled
severity 401910 wishlist reassign 401910 cron merge 401910 144710 quit * David Liontooth It's not an error - it's just he command echoed, telling syslog it was run. It's perfectly orderly, I just want to silence it, as it provides no relevant information. I've installed munin-node on seven machines and get the same messages in syslog for all of them (below). The configuration on these differ a fair amount. I tried to silence it with /dev/null 21 but that didn't do the trick, so I just commented out the line. This may still just be a cron configuration issue that munin simply triggers. Ah. Yes, these messages are cron simply logging that it started the job. The fact that the job produces no output doesn't stop cron from logging that, and as far as I know there is no way to tell cron not to log for each time it invokes a job. This isn't specific to Munin, you'll see similar messages when other cron jobs are run (I see the run-parts --report /etc/cron.hourly job being logged in your excerpt, for instance). There is an open bug report in the cron package, calling for this exact functionality. If it is added I shall surely update the Munin package to make use of it, but that's impossible right now. For that reason I'm merging your bug report with this one now. You can filter out the messages from cron in /etc/syslog.conf, though. If you change the one that directs messages to /var/log/syslog to read *.*;cron,auth,authpriv.none -/var/log/syslog no cron-related messages will be logged there (which includes all the non-munin-related messages, which may or may not be acceptable to you). You can instead, optionally, direct these messages to a separate log file with a line such as cron.* /var/log/cron.log I get a lot of street cred from my colleagues when showing them munin; they somehow imagine I put all of this information together myself ;-) :-) Dec 7 08:50:01 siena /USR/SBIN/CRON[13790]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 /dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 /dev/null; fi) [...] Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401910: munin-node: apt cron job runs even when apt plugin is not enabled
* David Liontooth $ cat /etc/cron.d/munin-node # # cron-jobs for munin-node # MAILTO=root # If the APT plugin is enabled, update packages databases approx. once # an hour (12 invokations an hour, 1 in 12 chance that the update will # happen), but ensure that there will never be more than two hour (7200 # seconds) interval between updates.. */5 * * * *root if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 /dev/null; elif [ -x /etc/munin/plugins/apt ]; t$ This cronjob should not be activated if the apt / apt_all plugin is not enabled. I think you've got a corrupted installation. This line should not end with «t$», it should read: */5 * * * * root if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 /dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 /dev/null; fi Could you try replacing it with the above, or reinstalling, and see if that helps? This job should never generate any output whatsoever if the APT plugins are disabled. I like a quiet syslog and discovered the bug from getting crowds of these. It's strange that you get it in your syslog, cron is supposed to mail output to root as per the MAILTO setting (even errors resulting from your corrupted file). Weird. What is the error that ends up in your syslog, exactly? Could you please paste an example? There are clearly some residual issues with munin and cron -- cf. #301361 #353979 #332285 #382947 None of these are about the cronjob of the apt plugin, so they're not related to the problem you're describing. That said, this works beautifully out of the box, so thanks for expert packaging. Thanks. :-) -- Tore Anderson
Bug#400122: sends unneccessary OK-summaries
* Holger Levsen Not anymore... (and the new /etc/init.d/munin-node also make use of those new lsb-function, though this is easily workaroundable by replacing it with the one from sarge ;) Ah, right, now I remember. If you're using it with the Sarge version of lsb-base you might experience problems using the stop parameter to the init script (there was an API change in lsb-base version 3.0-10). That's the reason the dependency is versioned. yes, i can say that it's not munin related. somehow the depends where broken and so i did apt-get install -f with purged munin or munin-node and thats what broke my configuration. Oh, okay. (Phew!) But, 1.2.5 seems to fix my 10:10-ok-summary problems - oh, no, lets wait, that cronjob is moved to 14:10 :) But if this is indeed the case, I will upgrade another installation and look again at those upgrade issues I had (while I was a bit stressed and didnt look closesly..) It changed to 10:14, not 14:10, actually... You have to read crontabs backwards. So it fixes the bug? If so may I just close this bug report? I have no chance of getting a fix for it applied to Sarge anyway (only critical fixes are accepted there). Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400122: sends unneccessary OK-summaries
* Holger Levsen I upgraded to the etch-version, which I even rebuild under sarge. Besides having an unresolvable depends on an lsb-base version which is not in sarge (which I fixed by using the old init-script and making the depends versionless :), Oh, right. I think the new lsb-base-package also is directly installable - at least it used to be. it also broke my config files, so that at the moment my munin configuration is broken, even after I downgraded to the sarge version again. Say what?! There's no code whatsoever in the maintainer scripts that would change your configuration, and breaking it during upgrades would be a serious bug. Could you elaborate on this, please? -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400122: sends unneccessary OK-summaries
* Holger Levsen first of all, let me say, that munin is great! :-) But I have one problem: I use the smart plugin to monitor my harddiscs and every day shortly after 10:00 (AM) I get an email: [...] After sending this mail to the munin-users mailinglist, I learned that these mails are send by this entry in /etc/cron.d/munin: 10 10 * * * munin if [ -x /usr/share/munin/munin-limits ]; then /usr/share/munin/munin-limits --force --contact nagios --contact old-nagios; fi Strange. This entry is supposed only to apply to contacts called nagios or old-nagios, why it would cause a message to be sent for your me-contact I don't really know. I've got a email contact almost the same as your in my munin.conf, and I don't get any such mails at ten o'clock. The differences is that I don't use the always_send directive, and I'm running version 1.2.5. Can you try without always_send, and see if it behaves the same, and also try upgrading to 1.2.5 (the Etch package should work directly on Sarge) and see if that helps? -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398374: Please make libpam-ldap/override default to false
Package: libpam-ldap Severity: wishlist The package will right now unconditionally overwrite configuration that quite possibly is user-modified. That's not the behaviour I expect from a Debian package, even though the file isn't tagged as a conffile. There's no guarantee that the user has seen the Debconf question (think for example DEBIAN_FRONTEND=noninteractive), and I am certainly not alone in not bothering to read all comments in the configuration file when I know exactly which directives I'm going to alter anyway. May I suggest using UCF instead? Then you don't have to bother with magic Debconf comments and asking permission to make changes, UCF will handle it for you seamlessly, and I will still feel that my custom configuration is still considered sacred and be safe knowing it won't vanish unexpectedly. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342872: munin-node: listens on 0.0.0.0:4949
* Tore Anderson I'll have a talk to Nicolai and point him to this bug log, and let him decide if the default should be changed or not - I'll respect his choice, and consider merging any eventual change in trunk to the 1.2.x branch. Nicolai has had another look at it and didn't change his mind, so the default will continue to be to bind all interfaces. I will keep this bug open until I merge back the documentation improvements, though. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342872: munin-node: listens on 0.0.0.0:4949
* Tore Anderson What issue is there that needs to be solved, exactly? * Marc Haber A potentially dangerous security issue. The code path from accepting to closing a connection according to the cidr_deny/deny configuration statements is fairly short and obvious so I'm sceptic as to whether this is a real concern or merely an academic one. If such a bug does exist, however, the issue would be critical regardless of the default configuration, as it could still be exploited by a user capable of connecting to 127.0.0.1, and in very many setups the node would be reconfigured to listen on all interfaces anyway (after all, it's what it's made for). I also note that packages such as Apache and others appear to employ a similar strategy as munin-node - listen on all interfaces, but restrict access to potentially sensitive data or functionality by way of application-specific access control lists. Listening on all interfaces was recently made the documented default (see http://munin.projects.linpro.no/changeset/1186), too.. It's of course possible to change this (at least in the developement trunk), so I'll have a talk to Nicolai and point him to this bug log, and let him decide if the default should be changed or not - I'll respect his choice, and consider merging any eventual change in trunk to the 1.2.x branch. (Oh and by the way, I fully agree that not having the loopback interface available inside a vserver sucks...) Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342872: munin-node: listens on 0.0.0.0:4949
* Marc Haber This possibility is now there, but the bug in the Debian BTS was not properly handled. I think this always have been possible - it's actually Net::Server that implements the functionality, and its host configuration option appears to be present in Sarge, too. I actually intended to close this bug when I realised that, but I forgot about it. However, the default in Debian's configuration is host * which does not solve the issue. Please consider changing the default to 127.0.0.1 I don't see what benefits you'll get from binding explicitly to the loopback interface, just a few disadvantages such as requiring deviation from upstream defaults, causing it to not work out of the box inside a vserver, and increasing the amount of configuration that must be done to allow remote Munin installations to query it (which'll probably increase support load as well). What issue is there that needs to be solved, exactly? Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395194: munin-node: typo in memory plugin info field
tags 395194 fixed-upstream quit * Ferenc Wagner subject says it all, see attached patch. In short: contigios - contiguous. Corrected upstream, thanks. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370347: Make etc/munin-node.conf automatically configurable
* Luk Claes In Debian-Edu one wants to add a line 'allow ^10\.0\.2\.2$' I see. Well, that certainly doesn't belong in the default configuration file. I have a suggestion, though. What if I add the following code (or something similar) to /etc/init.d/munin-node: --- munin-node.init (revision 1134) +++ munin-node.init (working copy) @@ -43,6 +43,7 @@ } . /lib/lsb/init-functions +[ -r /etc/default/munin-node ] . /etc/default/munin-node if [ ! -x $DAEMON ]; then log_failure_msg Munin-Node appears to be uninstalled. @@ -86,7 +87,7 @@ log_end_msg 0 exit 0 fi - start_daemon -p $PIDFILE $DAEMON + start_daemon -p $PIDFILE $DAEMON $DAEMON_ARGS ret=$? # start_daemon() isn't thorough enough, ensure the daemon has been # started manually Then your package could include the file /etc/default/munin-node, containing «DAEMON_ARGS=--config /etc/debian-edu/munin-node.conf». This file could be shipped as a conffile, or you could copy the default munin-node.conf in the postinst and apply your changes to the copy. Does this sound like an acceptable solution to you? Regards -- Tore Anderson
Bug#370347: Make etc/munin-node.conf automatically configurable
* Luk Claes Automatically configuring etc/munin-node.conf is not policy compliant for the moment as one needs to edit a conffile. A solution might be to include some file if it exists in the configuration... or to add a debconf question... Hi Luk, and apologies for answering so late. It has recently dawned on me that Etch is drawing near and that I need to start working on my packages again now if I am to make the freeze. :-) Anyway, I'm not really sure how to respond to this bug. I kinda like the fact that munin-node.conf is a conffile. Personally I have a strong preference that packages should just shut up and work out of the box, and that Debconf is overused - way too many packages asking all sorts of questions that have perfectly reasonable defaults, a trend that is futher aggravated when sloppy maintainers use end up using Debconf as some carte blanche to nuke user configuration. Boy do I hate seeing a comment à la «this file is maintained by debconf» in my configuration files. Sorry, that turned into a rant, but as you probably understand I'm reluctant to deprive munin-node.conf of its conffile status, and even more reluctant to introduce Debconf scripts to generate it dynamically. Before doing so I want to have a very good reason. That said, I'd like to help you see your problem solved, but I'm not really sure what it is, exactly. So a few questions: Do you believe the default configuration file is sub-optimal in any way? If so, what should be changed, in your opinion? If not (what you're trying to do would make sense only in Debian- Edu?), what exactly are you trying to do? You mention the possibility of adding a Debconf question, but you do not say what the question should be about. If I knew, maybe I could come up with another way to cater for your needs without making munin-node.conf a non-conffile or introducing Debconf scripts. Oh and by the way, the munin-node.conf format is dictated by Net::Server, so support for an eventual «include» configuration directive has to be added there, not in Munin itself. Cheers -- Tore Anderson
Bug#361433: munin: Munin needs Date::Manip
close 361433 quit * Martin Werthmoeller Munin needs the Date::Manip package, but there are no dependencies to libdate-manip-perl. That is inaccurate. The CGI functionality requires Date::Manip, that's true, but the CGI itself is optional, and not enabled by default. Munin will work quite well without Date::Manip in its default configuration. The libdate-manip-perl packages has been recommended since 1.2.0-1, though. I believe this is the proper thing to do, so I'm closing this bug. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364288: Bug#331435: xserver-xorg: Mouse pointer occasionally vanishes
close 364288 quit * Tore Anderson I've been running fvwm and KDE for more than two weeks now, and have not yet experienced a hang. So it appears that Openbox is triggering a bug in Xorg. I'll try to run it with debugging activated to see if I figure out something more. I think I've found out what causes it. The clock on my workstation is too fast, it needs only around two minutes and fifteen seconds to drift ahead one second. This makes ntpd step the time backwards, which appears to be what causes the hangs. Only happens sometimes, though, but I observerd a clear correlation between the hangs and clock stepping when I tested manually with ntpdate. Even though X11R6 had no problems with this, I'm closing this bug as it's unlikely to affect many users (it appears they'd need both to be running Openbox and ntpd, as well as to have defective hardware). -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385988: O: obconf -- Preferences manager for Openbox
Package: wnpp Description: Preferences manager for Openbox ObConf is a small graphical utility which configures the window manager Openbox' preferences and configuration settings on the fly. . If you're an Openbox user, you want this package. Enhances: openbox (= 3.0) -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382947: munin: Munin hangs on double cron-job execution and generates 100% cpu load doing nothing
tags 382947 moreinfo quit * Radek Antoniuk and of course sends ton of emails about it. zz:~# ps aux | grep munin munin 8769 0.0 0.0 6720 3296 ?Ss 11:40 0:00 /bin/sh -c if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi munin 8774 0.0 0.0 6720 3312 ?S11:40 0:00 /bin/sh /usr/bin/munin-cron munin 8823 0.0 0.0 6720 1648 ?S11:40 0:00 /bin/sh /usr/bin/munin-cron munin 8822 100 0.1 20336 15712 ?RN 11:40 11:03 /usr/bin/perl -w /usr/share/munin/munin-graph --cron root 9166 0.0 0.0 4016 1760 pts/1S+ 11:51 0:00 grep munin and: zz~# ls -l /proc/8822/fd/ razem 5 lr-x-- 1 munin munin 64 2006-08-14 11:45 0 - pipe:[1618978] l-wx-- 1 munin munin 64 2006-08-14 11:45 1 - pipe:[1619363] l-wx-- 1 munin munin 64 2006-08-14 11:45 2 - pipe:[1619363] l-wx-- 1 munin munin 64 2006-08-14 11:45 3 - /var/log/munin/munin-graph.log l-wx-- 1 munin munin 64 2006-08-14 11:45 4 - /var/lib/munin/munin-graph.stats.tmp and: zz~# strace -p 8822 Process 8822 attached - interrupt to quit Process 8822 detached zz:~# strace -p 8774 Process 8774 attached - interrupt to quit wait4(-1, unfinished ... Process 8774 detached zz:~# strace -p 8823 Process 8823 attached - interrupt to quit read(0, unfinished ... Process 8823 detached drogowskaz:~# Hmm, strange. It's the first time I've heard of such a problem, ever. Can you see anything out of the ordinary in /var/log/munin/*.log? The emails contains information of the lock files existing, I assume? Are you able to reproduce the problem at will, or was this a one-time occurrence? If so, could you try sudo -u munin /usr/share/munin/munin-graph --debug and mail me the output? I have a suspicion the spinning happens somewhere in RRDtool.. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382947: munin: Munin hangs on double cron-job execution and generates 100% cpu load doing nothing
== munin-node.log == I assume Nie ma takiego pliku ani katalogu means no such file or directory, but I'll need help with Połączenie odrzucone... :-) It's totally repeatable. When I kill all pids of munin-*, and wait for next cronjob, it happens again. Hmm. Could you change the cronjob so it says: */5 * * * * munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron --debug /tmp/debug-log 21; fi Hopefully it'll get stuck, and with any luck we'll see what happens near the end of /tmp/debug-log. Yeap, I can although it's quite big, I have just run it and it ends ok with no errors in fact. Hmm. Let's try the above first. Maybe that's an issue of cross-updating or sth. It should have worked... It seems it's munin-graph that gets stuck, so I don't think it has something to do with the node or the update process. Hopefully the log'll tell us some more. Other weird things is that every time it happens, there are two processes of munin-cron run at the exactly same time. Hmm. Could you next time take a look with ps axuf, to see if one is the child of the other? -- Tore Anderson
Bug#382947: munin: Munin hangs on double cron-job execution and generates 100% cpu load doing nothing
severity 382947 normal tags 382947 unreproducible quit * Radek Antoniuk Now, the problem is that I have resolved the problem.. or maybe not the problem itself. I thought about the two cronjobs running simultaneously, and then... I thought, ok, let's try to restart crond. And it worked. It seems like cron was running two things at a time or sth like that and they got mixed. Supposingly, the problem may happen again soon, but we will see about that. Okay. In the mean, I'll downgrade the severity of this bug, as I don't think it'll happen very often and affect many users. Therefore it's not worth dropping Munin from the next version of Debian over it. I hope you agree. If it happens again, though, let me know. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
retitle 380434 deal with /var/run/munin gone AWOL severity 380434 wishlist tags 380434 fixed-upstream quit * Paul Radford In an effort to reduce FS writes on a system with a solid-state disk, I mount /var/run as a tmpfs, i.e. ramdisk. Other packages do not mind and create their /var/run/xxx directories as required, e.g. bind. When /var/run/munin is not present after a reboot, munin-node refuses to start but does not issue an error message. You arbitrarily delete contents of the munin-node package, and then consider it a bug that it doesn't work any longer? Please. There's already code to handle this situation in the upstream repositories, however. (To support Ubuntu, which does the same thing as you do, for some strange reason.) For what it's worth you'll end up with double the amount of writes with your setup (mkdir+pidfile creation vs. pidfile creation only). Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
* Paul Radford
No, I consider it a bug that munin-node fails silently, without so much
as an error message. I was only able to discover the cause via strace.
When you yank out essential data from underneath dpkg, all bets are
off. Anyway, I cannot reproduce the silent failure you're describing:
[EMAIL PROTECTED] :) sudo /etc/init.d/munin-node start
Starting munin-node: FAILED!
The log brings more information:
2006/07/31-16:12:09 Couldn't open pid file /var/run/munin/munin-node.pid
[No such file or directory].
at line 268 in file /usr/share/perl5/Net/Server.pm
2006/07/31-16:12:09 Server closing!
That's munin-node 1.2.3-1, on Debian Woody.
I know that that is not a package maintainer's bug, but that you might fix
it in the same way as mldonkey was fixed, with an init script tweak:
http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg16629.html
The following patch was commited to SVN a while back:
Index: munin-node.init
===
--- munin-node.init (revision 999)
+++ munin-node.init (working copy)
@@ -65,6 +65,14 @@
start() {
log_daemon_msg Starting Munin-Node
+ # /var/run could be a tmpfs filesystem,
+ # make sure that the pidfile directory exists
+ PIDDIR=${PIDFILE%/*}
+ if [ ! -d $PIDDIR ]; then
+ mkdir $PIDDIR
+ chmod 0755 $PIDDIR
+ chown munin $PIDDIR
+ fi
if pidofproc -p $PIDFILE $DAEMON /dev/null; then
log_progress_msg started beforehand
log_end_msg 0
I haven't actually tried it, but it looks correct to me. (Don't know
if this is how mldonkey was handled, though.)
I'm not troubled by more writes on the tmpfs.
Duh, of course. Thinko.
--
Tore Anderson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
* Matt Zimmerman It isn't particularly strange; Ubuntu uses a tmpfs for /var/run now. Which is exactly what I find strange. I asked Tollef about it the other day, and understood it simplified some cleanup script slightly. Hardly something worth breaking heaps of packages, local applications and distribution compability over, in my humble opinion. Anyway, the next version of Munin will handle this situation (and I believe my co-maint has already uploaded a version with the fix to Ubuntu's universe). -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
* Paul Radford That's what I get for setting log level to 0 in munin-node.conf (/var mounted read-only), I guess. *slaps forehead*. I had been looking for a stdout message, but again that's upstream's decision. Sorry. I believe that by the time it bombs out, it has already detached from the terminal, so it's unable to print it there. (I may be mistaken, though.) Stdout message or no, as long as the init script correctly detected that the start of the daemon process failed, printed a FAILED message to warn about that (and gave the correct return code), I feel more cannot be expected. But of course, patches would be welcome. ;-) I just hope I get around to preparing a new release soon. There hasn't been much activity neither from upstream nor me lately, I'm afraid... It'll probably be more fun to be indoors in autumn! -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
* Matt Zimmerman That isn't accurate. It solves a number of real problems, such as the situation where a pid file needs to be written there, but the root filesystem is mounted read-only (or even not mounted yet, e.g. initramfs). Good point. Would've been nice if those files were moved back to a proper /var/run as soon as possible after it became writable, though. That would probably have fixed the early-userspace problem without breaking late-userspace. But I guess it's too late for that now. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379138: fails to start if there's labeled addresses present
Package: dhcp3-relay Version: 3.0.4-6 Severity: important I believe the following terminal log tells the full story: [EMAIL PROTECTED] :) sudo dhcrelay3 -i eth0 -d 10.0.0.1 Internet Systems Consortium DHCP Relay Agent V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/eth0/00:50:8d:55:6a:fe Sending on LPF/eth0/00:50:8d:55:6a:fe Sending on Socket/fallback ^C [EMAIL PROTECTED] :( sudo ip a a 192.168.1.1/24 dev eth0 label eth0foo [EMAIL PROTECTED] :) sudo dhcrelay3 -i eth0 -d 10.0.0.1 Internet Systems Consortium DHCP Relay Agent V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Can't get interface flags for eth0foo: No such device For some reason it assumes «eth0foo» is a device of its own, which is not the case (doesn't show up as a separate interface in /proc/net/dev nor in the output of «ip a s»). It fails like this even when I ask it to listen on another interface which doesn't have labeled addresses, as long as a labeled address exist on a (unrelated) interface. Regards Tore Anderson -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-k7 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Versions of packages dhcp3-relay depends on: ii debconf [debconf-2.0] 1.5.2 Debian configuration management sy ii debianutils 2.16.2 Miscellaneous utilities specific t ii dhcp3-common 3.0.4-6Common files used by all the dhcp3 ii libc6 2.3.6-15 GNU C Library: Shared libraries dhcp3-relay recommends no packages. -- debconf information: * dhcp3-relay/servers: 10.0.0.1 * dhcp3-relay/interfaces: eth0 * dhcp3-relay/options: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373716: munin-node: Please use ip_ plugin instead of if_
close 373716 quit * Jerome Warnier 2) the initscript should ensure that the iptables rules are loaded, and load them if necessary. I feel I cannot do this. Munin has no authority over the iptables ruleset, so I cannot just change them arbitrarily - that might cause breakage. I know I'd be furious if a package did that to my ruleset. Besides, ip_ and if_ are orthogonal - ip_ graphs traffic to/from a specific IP address, while if_ considers network interface traffic, which might not be IP at all. I'm therefore closing your bug report. Thanks -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373716: munin-node: Please use ip_ plugin instead of if_
reopen 373716 clone 373716 -1 retitle 373716 if_ shouldn't claim ip_ is a direct alternative severity 373716 minor tags 373716 upstream retitle -1 ip_ needs to be run as root to work properly quit * Jérôme Warnier I can understand, I thought about this but I felt like the rules needed are not intrusive at all: iptables -A INPUT -d 192.168.0.1 iptables -A OUTPUT -s 192.168.0.1 So if you're DROP-ing traffic above those rules (which is very likely, especially in the INPUT chain), the rules won't hit, and the graph will be wrong. If you've used -I INPUT 1 instead you'd shuffle around all other rules in the chain, which is even more undesireable. Also, the second the administrator reloads his ruleset the rules will be lost and the graphs stop working. Maybe the script should just verify if such accounting rules are present in chains INPUT and OUTPUT first. Then it could work. It does, but because it isn't run as root by default it doesn't work correctly. I've made a new bug about this. Another option: base ip_ on something else than iptables (maybe /proc or/sys?). I don't think the information is available anywhere else, at least not where it's practical to access it. I'll be happy to be proven wrong, though. - provide a patch for Debian not to advertise a concerning warning message when using if_ (because here, my bug was actually the error message) and/or: - talk about this issue with upstream (forward upstream). I agree, and I'll probably commit a fix to the upstream repository myself when I get around to it. I've reopened the bug, and clarified what it's about. Thanks -- Tore Anderson
Bug#372551: munin-node: init script never returns
close 372551 quit Hi, Uwe. * Uwe Storbeck /etc/init.d/munin-node start never returns and makes the system hang on boot. I can reproduce the effect if I call it from the command line. It hangs in a read pid command. I'm not sure if this is a bug of the munin-node init script itself or of some other scripts or programs it calls. The latter. The bug is in lsb-base (#370155), and was fixed in the 3.1-9 version of that package. So I'm closing your bug. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364288: Bug#331435: xserver-xorg: Mouse pointer occasionally vanishes
* Tore Anderson So the only suggestion I have left is that Openbox is somehow triggering a bug in X11R7, or vice verca. In the latter case, however, it is weird that the state remains even after Openbox is killed and another window manager is started in its place. Openbox hasn't changed in a while, either... In any case, I'm running fvwm now, to see if the hang also occur in an X session where Openbox has never been present. I haven't seen a hang yet, but I have done it for too short to conclude yet. I'll keep you posted. I've been running fvwm and KDE for more than two weeks now, and have not yet experienced a hang. So it appears that Openbox is triggering a bug in Xorg. I'll try to run it with debugging activated to see if I figure out something more. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364288: Bug#331435: xserver-xorg: Mouse pointer occasionally vanishes
* Michel Dänzer Both of you, please also make sure (e.g. using xlsclients) that there are no 'hidden' clients that could interfere, and that killing the clients actually causes them to close their X display connection (and possibly open a new one). I checked this, there is no client left, except the one started by xinit. Usually this is my window manager Openbox, but I did try once to make xinit start an xterm instead, and then start Openbox afterwards. That enabled me to kill Openbox without also pulling down the X server - without that having any effect. I started another window manager afterwards (Window Maker, if I recall correctly), but yhe defunct state persisted. So the only suggestion I have left is that Openbox is somehow triggering a bug in X11R7, or vice verca. In the latter case, however, it is weird that the state remains even after Openbox is killed and another window manager is started in its place. Openbox hasn't changed in a while, either... In any case, I'm running fvwm now, to see if the hang also occur in an X session where Openbox has never been present. I haven't seen a hang yet, but I have done it for too short to conclude yet. I'll keep you posted. Regards -- Tore Anderson
Bug#364288: Randomly loses input since X11R7 upgrade
Hello Michel, * Michel Dänzer Some semi-random ideas to try and narrow down the problem: * Kill the running X apps one at a time and see if the problem goes away after killing any of them. Didn't help. After Openbox were the last client remaining I restarted it too using SIGUSR1, no go. * Add Option AllowClosedownGrabs to xorg.conf Section ServerFlags and press Ctrl+Alt+Keypad-Multiply when the problem occurs. No effect. (I tested that it worked correctly before the hang, too.) * Do not load the type1 and/or freetype X server modules. If you actually need their functionality, an X font server such as xfs should serve as a replacement. I have no idea what functionality they provide, they've just been in my config file in my years. :-) Anyway I removed them (without noticing any difference in how the fonts looked), but it did not prevent a hang. You can only attach to the X server with gdb remotely from another machine (or at the very least from console), as otherwise you end up in a dead lock where gdb stops execution of the X server, which is what provides interaction with gdb... Ehh... *blushes* Anyway, I attached GDB to the X server from the console, put it in a screen and attached to it from within X. When the hang occurred there were no signals or anything else showing up. So that didn't make me any wiser either. :-( Regards -- Tore Anderson
Bug#364288: Randomly loses input since X11R7 upgrade
* Tore Anderson Yep, it did, using 2.6.15-1-k7. I ran that kernel for a long time with X11R6 on top and didn't have any problems at all, so it seems very unlikely that the kernel is to blame. Hi David, Do you think there's any hope of getting nearer any solution to this bug in forseeable future? I'm sorry, but this is making my workstation so useless that I'll soon downgrade to etch or change to some other distribution in the hope that this bug only appears in the Debian builds. I tried to attach GDB to the X server but then it just froze solid, both with the binary NVidia driver, and with the included one. I don't know if there is any other debugging possibilities at all? Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364288: Randomly loses input since X11R7 upgrade
* Tore Anderson I will try downgrading my kernel now and see if it still happens. Yep, it did, using 2.6.15-1-k7. I ran that kernel for a long time with X11R6 on top and didn't have any problems at all, so it seems very unlikely that the kernel is to blame. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364288: Randomly loses input since X11R7 upgrade
* David Martínez Moreno I think that you could use xev in order to know if X.Org is receiving input: I am supposing you are capable of making the failure happen quickly (more or less). First launch a terminal and a browser in the same desktop. Then use xwininfo in order to obtain the ID of the browser. Then launch xev -id WINDOW_ID in the terminal and feel free to surf. As you will see, xev intercepts *every* event belonging to the window (key presses, mouse movements, etc.). When it happens, you can tell us if you start to lack output in the xev terminal. If so, I would guess for a kernel problem. If not...well, we could try another thing. :-) I thought of this a few minutes after writing my original report, but obviously forgot to follow up with my results. I'm at work now, so this is from memory, but what I did was something like this (when the breakage happened): 1) Change to another VT (with the help of Alt+SysRq+R). 2) From there start DISPLAY=:0 xev 3) Change back to the VT with X, where xev now is visible and has input focus according to my window manager And then batter the keyboard, move the pointer around, hit mouse buttons, and so on, and change back to the VT where xev was started to inspect the output. The result: No MotionNotify, KeyPress/Release, or ButtonPress/Release events at all. The only ones were some Expose and Visibility*-events (can't quite remember the order of them, though). I'm using focus-follows-pointer, but the focus do not change from the xev window when I move the pointer to some other window, so the window manager appears to be oblivious to the MotionNotify-events too. It seems as if the X server simply stops sending those events. It might of course be a kernel bug - I did indeed upgrade to 2.6.16 recently. I can try downgrading to 2.6.15 and see if I experience the bug then. The X server is my prime suspect though - the keyboard works perfectly on the console, and I need only restart X to fix the problem. I will install GPM to see if the mouse continues working fine on the console when X has problems. One thing that really makes me think the kernel is unlikely, is the fact that the pointer actually moves around the screen when I move the mouse, so the X server has to receive the events from the kernel orelse the pointer would appear to be stuck/frozen, no? Yet there's no MotionNotify-events - I assume the kernel doesn't have anything to do with generating those? I will attach an xev to my browser like you suggested and see if I get the same results. However I'm unable to reproduce it at will, it just happens once in a while - and I can't guarantee that I will be browsing when it happens. I'll try (from the console) to attach xev to whatever window had focus if that happens, though. I guess I can use xwininfo -name to get the window ID without having to rely on the mouse working, so that should be no problem. Another thing I just thought of and I'll try is to remove all the USB- related modules and re-insert them again, to see if that will fix the problem without requiring a restart. Both my keyboard and my mouse are USB devices. I did try hotplugging them though, without any success. Kind regards -- Tore Anderson
Bug#364288: Randomly loses input since X11R7 upgrade
Package: xserver-xorg Version: 1:7.0.14 Severity: important First off, apologies for the lack of detail in this bug report. I simply do not know what's going on nor how to debug it. :-/ After my latest dist-upgrade, which pulled in X.Org 7, the X server has started randomly losing input. When it ends up in this state, no input is accepted whatsoever, all keypresses and mouse button clicks does not appear to be processed at all (even the keyboard LEDs won't change if I hit e.g. Num Lock). The only thing that keeps working is the mouse pointer, which moves normally when I move the mouse. I believe every time the server has entered this state I've been using the mouse for something. It doesn't seem to happen unprovoked - I've never woken up to the server having entered the defunct state during night, for instance, while when actively using the computer it usually happens within a few hours. I don't use the mouse for much, though, so I suspect it might happen more frequently if I used it more. I've experienced the problem both using the nv and nvidia drivers, and also both when using the evdev and mouse drivers for my mouse device. There's nothing relevant in /var/log/Xorg.0.log, nor in ~/.xsession-errors. The X server itself is completely unuseable when it occurs, and I have found no way of reviving it. It doesn't seem to be another way out than to change to another VT (after having set the keyboard to raw mode using Alt+SysRq+R), and from there do a full restart of X. I have no idea how to debug this further, so any suggestions on how to get to the bottom of this would be much appreciated. Kind regards Tore Anderson -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages xserver-xorg depends on: ii debconf 1.5.0 Debian configuration management sy ii nvidia-glx [xserver-xorg-vid 1.0.8756-4 NVIDIA binary XFree86 4.x driver ii x11-common 1:7.0.14X Window System (X.Org) infrastruc ii xbase-clients1:7.0.0-4 miscellaneous X clients ii xkb-data 0.8-5 X Keyboard Extension (XKB) configu ii xserver-xorg-core1:1.0.2-5 X.Org X server -- core server ii xserver-xorg-input-kbd [xser 1:1.0.1.3-2 X.Org X server -- keyboard input d ii xserver-xorg-input-mouse [xs 1:1.0.4-2 X.Org X server -- mouse input driv Versions of packages xserver-xorg recommends: pn discover1 | discover none (no description available) pn laptop-detect none (no description available) pn mdetect none (no description available) pn xresprobe none (no description available) -- debconf information: * xserver-xorg/multiple_possible_x-drivers: xserver-xorg/config/monitor/use_sync_ranges: true * xserver-xorg/config/inputdevice/mouse/port: /dev/input/mice * xserver-xorg/config/monitor/lcd: true * xserver-xorg/config/doublequote_in_string_error: * xserver-xorg/config/monitor/screen-size: 17 inches (430 mm) * shared/default-x-server: xserver-xorg * xserver-xorg/autodetect_monitor: true * xserver-xorg/config/inputdevice/mouse/protocol: ImPS/2 * shared/no_known_x-server: * xserver-xorg/config/display/default_depth: 16 * xserver-xorg/config/display/modes: 1600x1200, 1280x1024, 1280x960, 1152x864, 1024x768, 800x600, 640x480 * xserver-xorg/config/device/bus_id_error: * xserver-xorg/config/inputdevice/keyboard/internal: * xserver-xorg/config/monitor/vert-refresh: 50-75 * xserver-xorg/config/inputdevice/keyboard/options: * xserver-xorg/autodetect_keyboard: false * xserver-xorg/config/inputdevice/mouse/zaxismapping: true * xserver-xorg/config/device/use_fbdev: * xserver-xorg/config/inputdevice/keyboard/variant: * xserver-xorg/config/nonnumeric_string_error: xserver-xorg/config/fontpath/fontserver: * xserver-xorg/config/inputdevice/keyboard/layout: no * xserver-xorg/config/modules: GLcore, bitmap, dbe, ddc, dri, extmod, freetype, glx, int10, record, speedo, type1, vbe * xserver-xorg/config/monitor/identifier: Generic Monitor * xserver-xorg/config/inputdevice/mouse/emulate3buttons: true * xserver-xorg/autodetect_mouse: true * xserver-xorg/config/monitor/horiz-sync: 30-94 * xserver-xorg/config/device/video_ram: * xserver-xorg/config/monitor/range_input_error: * xserver-xorg/config/write_dri_section: true * xserver-xorg/config/inputdevice/keyboard/model: pc105 * xserver-xorg/config/device/driver: nvidia * xserver-xorg/config/device/identifier: NVIDIA Corporation NV18 [GeForce4 MX - nForce GPU] * xserver-xorg/config/monitor/selection-method: Medium * xserver-xorg/config/null_string_error: * shared/multiple_possible_x-servers: * xserver-xorg/config/device/bus_id: * xserver-xorg
Bug#341703: Description should mention limitations
Hi. I was made aware of this bug from the latest changelogs. The description state: It is similar to the resize2fs program from e2fsprogs, but support online resizing, this allows to enlarge mounted filesystem. Online resizing require a kernel patch. This is at best partially correct. Linux has supported online resizing since 2.6.10; no patch is required. Another thing worth mentioning is that the developement version of resize2fs have support for online resizing, this will be included in the next release of e2fsprogs. (See the latest comments in #351720.) -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341703: Description should mention limitations
* Petter Reinholdtsen This sounds very good. I tried online resizing with kernel 2.6.15-1-686-smp on etch, and was unable to get it working. Is this supported for ext2 or ext3, or both? How can I verify that it is working? I tested using ext2online. Is this the wrong tool to use? Hmm. It doesn't work anymore with ext2resize 1.1.19-4. If I downgrade to 1.1.19-3, it works again. You've broken it! Bad, bad Petter! :-) Log: [EMAIL PROTECTED] :) sudo lvcreate -L2G -ntest echo Logical volume test created [EMAIL PROTECTED] :) sudo mke2fs -O has_journal,resize_inode /dev/echo/test 1G mke2fs 1.39-WIP (31-Dec-2005) Etichetta del filesystem= Tipo SO: Linux Dimensione blocco=4096 (log=2) Dimensione frammento=4096 (log=2) 131072 inode, 262144 blocchi 13107 blocchi (5.00%) riservati per l'utente root Primo blocco dati=0 Maximum filesystem blocks=268435456 8 gruppi di blocchi 32768 blocchi per gruppo, 32768 frammenti per gruppo 16384 inode per gruppo Backup del superblocco salvati nei blocchi: 32768, 98304, 163840, 229376 Scrittura delle tavole degli inode: fatto Creazione del journal (8192 blocchi): fatto Scrittura delle informazioni dei superblocchi e dell'accounting del filesystem: fatto Questo filesystem verrà automaticamente controllato ogni 33 mount, o 180 giorni, a seconda di quale venga prima. Usare tune2fs -c o -i per cambiare. [EMAIL PROTECTED] :) sudo mount /dev/echo/test /mnt [EMAIL PROTECTED] :) df -hP /mnt Filesystem Dimens. Usati Disp. Uso% Montato su /dev/mapper/echo-test 1008M 34M 924M 4% /mnt [EMAIL PROTECTED] :) sudo ext2online /mnt ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b [EMAIL PROTECTED] :) df -hP /mnt Filesystem Dimens. Usati Disp. Uso% Montato su /dev/mapper/echo-test 2,0G 34M 1,9G 2% /mnt Using 1.1.19-4, the ext2online step yields: ext2online v1.1.19 - 2001/03/18 for EXT2FS 0.5b ext2online: unable to resize /dev/mapper/echo-test There's only code for online resizing in ext3, not ext2 (in the kernel.org tree, anyway). See /usr/share/linux/fs/ext3/resize.c. Also the current resize2fs program from e2fsprogs Mercurial repository is able to do online resizing (tested it and it works fine), so IMHO the ext2resize suite is quickly losing its relevancy... I don't really see why anyone would want to use these tools over the ones included in e2fsprogs, as the latter obviously enjoy much better upstream maintenance. Only ext2prepare-equivalent functionality is missing from e2fsprogs now. I'm using an unmodified linux-image-2.6.15-1-k7 (version 2.6.15-8), by the way. Cheers -- Tore Anderson
Bug#341703: Description should mention limitations
* Petter Reinholdtsen I have no strong feelings either way, but want to have all the tools needed for online resizing of ext3 (and preferably ext2) in Debian. When is the new e2fsprogs with online resizing support going to show up in debian? Until that happen, ext2online have a mission. :) I don't know, you'll have to ask Ted Ts'o. But the code is there already, and e2fsprogs are uploaded quite often, so I suspect the answer is soon. And even after that happen, ext2online have a mission for those with documentation and scripts using it. :) Mhm. If it can be made bug-free, anyway. Currently I think it would be better to remove ext2online/ext2resize and just point people to e2fsprogs (when the new e2fsprogs version hits the archive, that is). This package wasn't included in Sarge, and it doesn't look too good with regards to Etch either. Besides, I've been fortunate enough to have had dinner with Ted Ts'o where we discussed filesystems amongst other things. The guy is truly paranoid about data security, which is a GOOD thing. :-) I trust e2fsprogs much more than any other filesystem utility suite available. In contrast to e2fsprogs, the tools for XFS, JFS, and ReiserFS have all let me down. I must admit I don't trust the ext2resize tools either. Quoth Ted Ts'o: «ext2prepare is so scary that I refuse to simply suck it into e2fsprogs until I rework it significantly (and this may require a rewrite from scratch)». Comments like this from a programmer whose code I trust very much doesn't exactly make me want to use ext2prepare on file systems containing valuable data... Are anyone working on fixing that? Ted described it as pending. I don't really know when he plans to implement it or how long it will take (#351720 is a wishlist for this exact feature, you might want to monitor it). I hope the mke2fs options to enable online resizing will become default. I suspect it will be a pain to get '-O has_journal,resize_inode' into d-i to make sure the partitions created by the installer can be resized. I hope so as well. (has_journal is implicit for ext3 file systems, though.) Aren't you involved with d-i developement? A wishlist couldn't hurt in any case I guess. Thank you for the new information. I'll try to adjust the package description to reflect what I have learned in this thread. No problem. :-) I hope that we'll soon have decent support for Ext3 online resizing in Debian (and other distros as well). Regards -- Tore Anderson
Bug#226077: Is this bug still present?
* Javier Kohen This bug is old and the aforementioned desktop system is no more. Should we close this bug? Probably, but I'll leave that up to David Weinehall, ScummVM's new maintainer. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353979: munin-limits: cron job has --force option set, results in spurious emails
* Steve Gran Looking through the code, it seems to me that this is because --force is set. I see no place in the code where foporce does anything reasonable, so for now I have pulled it out of /etc/cron.d/munin. Is there some reason it is enabled by default? Well, --force is supposed to send out a trap even if the service was OK to begin with (thus simulating a transition from warning or critical to OK). It is however only supposed to do this for the special Nagios contacts, hence --contact nagios --contact old-nagios in the cron job. This works for me. Is your contact by any chance called nagios or old-nagios? If that is the case, please rename it. If not, please check if /var/lib/munin/limits looks sane with regard to permissions and contents, and report back. Thanks -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353452: LC_NUMERIC support
close 353452 quit * Martin Buck Don't get me wrong - I can fully understand the motivation behind your request, but I simply don't think that calc is the kind of application that should be locale-dependent. IMHO, this is something for GUI calculators or really simple command-line calculators, but not for complete programming languages with a well-defined syntax that would break due to changes like this. So you'll get my standard reply: I'm only packaging calc for Debian, but I'm not one of its developers. If you can convice the upstream developers that adding locale-support to a future release would be a good thing (and they find a clean way to do it), then this change will appear in the Debian package automatically. Just don't expect me to lobby for this change. No problem. It was only a wishlist anyway; refusing those is perfectly legitimate. :-) So as there's no point in having the report stick around to clutter your bug list, I'm closing it. Cheers -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353452: LC_NUMERIC support
* Martin Buck I'm not convinced that this would be a good thing. calc effectively is a programming language, and making the syntax of a programming language dependent on locale settings doesn't sound like a good idea to me (if gcc started to do that, I'm pretty sure it would get a few grave bugs within seconds of the upload). Personally I use it mostly as an interactive application, for whenever I need to do some calculation. I just like it better than bc. Anyway, in this case it is somewhat annoying that I always have to remember to use some foreign syntax of specifying the radix point. Also I usually cannot copy/paste numbers from documents or outputted by other programs into calc. It would be nice if it worked with the comma, that's all. And what should calc do with those operators that become inaccessible because LC_NUMERIC's decimal separator clashes with them (like ',' in your case)? No idea, really. I wasn't aware that the comma had some special meaning to calc. If it hadn't it could probably had been made to interpret both the period and the comma as the radix point, which would ensure backwards compability as well as satisfy me. I'm no authority on the subject, but I think those two are the only ones that are generally used. In any case, the output should in my humble opinion heed $LC_NUMERIC: C-style arbitrary precision calculator (version 2.11.11) Calc is open software. For license details type: help copyright [Type exit to exit, or help for help.] ; 1 / 2 0.5 That should've printed 0,5, given my locale. Kind regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353607: Globbing handles multibyte characters incorrectly
Package: zsh Version: 4.3.0-dev-2-4 Hi. I recently started using UTF-8, and noticed that zsh doesn't handle multibyte characters correctly when globbing, as demonstrated below: [EMAIL PROTECTED] :) touch øl [EMAIL PROTECTED] :) ls ?l zsh: no matches found: ?l [EMAIL PROTECTED] :( ls [ø]l zsh: no matches found: [ø]l [EMAIL PROTECTED] :( ls ??l øl [EMAIL PROTECTED] :) Regards -- Tore Anderson
Bug#353452: LC_NUMERIC support
Package: apcalc Severity: wishlist Hi. It would be great if calc supported LC_NUMERIC: $ LC_ALL=nn_NO calc '0,5 + 0,5' Line 1: unused value ignored Line 1: unused value ignored 5 The expected result here would be 1, as the Norwegian decimal separator is the comma (as it is in many other countries as well). -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341763: Wrongly claims fully-qualified hostnames are invalid
* LaMont Jones I have not NMUed hostname in Debian. I did upload the package with my patch to Ubuntu though. *boggle* Well, I'll be damned. I must have rebuilt it myself and forgotten all about it. :-) Sometimes my fondness of whisky gets the better of me.. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341763: Wrongly claims fully-qualified hostnames are invalid
* Graham Wilson I think the rules that LaMont posted were the rules for FQDNs. My contention is that the kernel hostname variable is not meant to contain FQDNs, but only hostnames, which are single components of domain names (and therefore have not dots in them). Is there disagreement about this? I cannot say what usage the good folks from ATT Bell Labs originally had in mind (if that was indeed where the hostname concept was invented). However, using FQDN hostnames has been de facto allowed for a long time, both in the various Linux distributions, and other Unices. Some distributions use it as the default, if I'm not mistaken. I won't argue that FQDN hostnames is more correct than unqualified hostnames or vice verca; I consider it a matter of personal preference. I prefer the former, you the latter. Fine by me. Both setups work perfectly, and both setups are valid according to established pratise. Now, what I do strongly object to is that you appear to want to disallow FQDN hostnames, without citing a single authoritative reference that indicates that FQDN hostnames are de jure forbidden. As I stated before, «I believe [...]», or the more recent «My contention is [...]», type of argumentation isn't really convincing as long as you do not back it up with some kind of standards document. And even if you do find an RFC or similar which states clearly states that the kernel hostname MUST NOT be fully qualified (I looked and found nothing), I would still not enforce it without first giving it some careful consideration, given how long it has been de facto permitted. It is not a change to be done lightly, in my opinion. Who knows how many thousands, if not millions, of installations will start claiming their hostnames are invalid? I have several hundred... Even though I'm currently convinced the current behavior is correct, I don't think the stringent checking code adds anything terribly useful over what was there in the past, so it seems likely that I'll decide to remove it. Hmm. You are aware that LaMont did an NMU a while back, right? Regards -- Tore Anderson
Bug#341763: Wrongly claims fully-qualified hostnames are invalid
* Graham Wilson
I disagree with this patch. I believe the kernel hostname variable
(the one that hostname(1) sets, and that {get,set}hostname(2) query
and set) should not be a FQDN. Instead the FQDN should be looked up
using gethostbyname(3) (which will in turn query /etc/hosts or a
nameserver).
Does someone else have a reason why this is not the case?
You are the one who wants to change the status quo, as well as impose
an additional restriction that is not present in any other Linux
distribution, including Sarge, or any other Unix[-lookalike] I tested.
In my opinion, that makes the burden of proof lie on you. And «I
believe [...]»-argumentation is NOT good enough. LaMont has cited RFCs
supporting his (and my) opinion. If you can't do the same, well, then
I can't see any reason to have this discussion at all.
Kind regards
--
Tore Anderson
Bug#298284: Please enable CONFIG_MEGARAID_MAILBOX in the 2.6 kernels
close 298284 quit CONFIG_MEGARAID_MAILBOX has been enabled for quite some time already; obviously someone forgot to close my wishlist. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294066: Pid file handling broken
tags 294066 +patch
quit
* Patrick Caulfield
multipathd is started very early on in the boot process. often
before /var is mounted. PID files go in /var/run and if that dir
doesn't exist the PID file handling is even more (and dangerously so)
broken.
I see that you've backed out the patch that originally caused me to
submit this bug, as multipathd now is started later in the boot
process. Simply running multipath early and defer multipathd startup
until later was a good solution to that problem, by the way.
However, the pid file handling is still broken, but this time it is
the init script that is the problem. It looks for the file
multipath-tools.pid, while it is actually called multipathd.pid.
Trivial patch included:
--- /etc/init.d/multipath-tools~2006-02-11 13:58:34.0 +0100
+++ /etc/init.d/multipath-tools 2006-02-11 14:00:07.0 +0100
@@ -2,7 +2,7 @@
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/sbin/multipathd
-NAME=multipath-tools
+NAME=multipathd
DESC=multipath daemon
test -x $DAEMON || exit 0
@@ -36,7 +36,7 @@
echo .
;;
*)
- N=/etc/init.d/$NAME
+ N=/etc/init.d/multipath-tools
echo Usage: $N {start|stop|restart|reload|force-reload} 2
exit 1
;;
--
Tore Anderson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352354: ASN lookup in traceroute mode
Package: hping3 Severity: wishlist It would be very nice if hping3 (and hping2 for that matter) could do ASN lookups while in traceroute mode. RIPE NCC's RISwhois service is probably the best candidate for doing the necessary IP - ASN lookups. Compare traceroute-nanog used with the -A command line option. Thanks -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351720: tune2fs -O resize_inode
* Theodore Ts'o Support for the on-line resizing inode has been integrated into e2fsck, mke2fs, and resize2fs (so that the off-line resizer knows about the resize inode, and can optimize its resizing activities when shrinking or growing a filesystem with a on-line resize inode). Ohh, I wasn't aware of the last part there about resize2fs. Cool! So if you create a filesystem from scratch, you can indeed create it with with the resize inode. However, ext2prepare is so scary that I refuse to simply suck it into e2fsprogs until I rework it significantly (and this may require a rewrite from scratch). Basically, I'm not willing to maintain it and vouch for it not trashing user's filesystems in its current state. I know that mke2fs supports creating the resize inode - orelse I wouldn't have submitted #346580. :-) And I didn't mean to suggest that you should just copy ext2prepare verbatim into e2fsprogs without any quality checking! I had my suspicions that its code quality were way below par... Thanks for confirming that. So unfortunately, there is no way to safely add an on-line resize inode to an existing filesystem using e2fsprogs. This is definitely an undesirable state of affairs, but it's a matter of me finding time to fix up ext2preprae. Yep. And even though it /might/ be safe to use ext2online followed by e2fsck I wouldn't even trust my web browser cache to that process... So effectively there is currently NO way to safely add a resize inode to a filesystem. Which indeed is an undesireable state of affairs, as you so eloquently put it. Especially considering that most distributions (including Debian, as far as I know) create filesystems lacking the resize inode during their installation process. You mean the tool to trigger the on-line resizing functionality in the kernel? That's probably easier for me to move into e2fsprogs. Yes. However, I think it does more than just tell the kernel to start a resize process. If I have understood correctly the kernel itself is only able to resize filesystems to sizes that are multiples of a certain size (128MB for filesystems with a 4k block size, if http://ext2resize.sf.net/online.html are to be believed). The rest is done by the tool itself somehow... But don't take my word for it. :-) From my sparse testing the ext2online tool appears to work correctly. I haven't been able to make it corrupt any filesystem yet, anyway. However due to the state of the ext2resize package as a whole it doesn't look like it's ever going to make it any stable release of Debian, and probably not any other distro either. That's why it would be very nice to see that functionality replicated in e2fsprogs as well as ext2prepare-equivalent functionality, so that e2fsprogs can do everything the ext2resize tools could, effectively obsoleting it. However, even though I would trust an ext2online-ish tool developed by you much more than the one that's currently available, it would be possible to have a complete resizing suite in stable if either ext2prepare is fixed (I seriously doubt that will happen) or equivalent functionality is added to e2fsprogs, and the RC bugs of ext2resize are dealt with by simply removing the ext2resize (#285257) and ext2online (#348778) tools from the package. That's why this whishlist bug is primarily about implementing ext2prepare-like functionality - if that happens I will try to convince ext2resize's maintainer to fix his RC bugs that way - unless you add ext2online-like functionality as well, of course, in which case I couldn't care less about ext2resize. :-) Kind regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351829: Full client/server separation
Package: azureus Severity: wishlist I have a headless server in my closet that's running 24x7, which cannot be said of my workstation. It would be really nice if it was possible to run the network part of Azureus permanently on the server, and have the UI connect to it instead of to localhost:6880. That way I could keep seeding even though my workstation is switched off or whatever. (An init script would be appreciated if such a feature was added.) Kind regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300202: munin-node: plugin df_abs should allow long device names
forwarded 300202 http://munin.projects.linpro.no/ticket/85 quit * Herbert Thielen Munin allows long device names now, but df_abs still generates abbreviated ones, so that ambiguous values may be transferred if two long-named devices have the same endings. Hi Herbert. Thanks for reporting this, I've forwarded the bug to the upstream tracker at the URL above. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311727: /usr/share/perl5/Munin.pm: munin-cron causes lots of mails (through Munin.pm)
forwarded 311727 http://munin.projects.linpro.no/ticket/91 quit * Sven Mueller munin-cron causes pretty many mails to be sent on my system. Hi Sven, and thanks for reporting. I've forwarded the issue upstream. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303254: munin-node: irqstats error on sparc64
forwarded 303254 http://munin.projects.linpro.no/ticket/88 quit * Chad Walstrom String matching isn't geared for what sparc reports, evidently... Hi. Thanks for reporting. I've forwarded this issue upstream. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314610: munin-node: wrong regexp in apt_all
forwarded 314610 http://munin.projects.linpro.no/ticket/92 quit * Raoul Borenius this patch makes packages which are on 'hold' show up correctly again. Hi Raoul, thanks for reporting. The issue has been forwarded to the upstream tracker found at the URL above. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326818: shell /bin/false renders smart plugins unusable
forwarded 326818 http://munin.projects.linpro.no/ticket/93 quit * Sebastian Wiesinger The munin user is created with '/bin/false' as shell. Using this shell prevents the smart_ and hddtemp_smartctl plugins to run when called from munin-cron. Hi Sebastian, thanks for the report. I've passed the issue on to the upstream bug tracker as referenced above. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336618: munin: blurry graphs after rrdtool upgrade
forwarded 336618 http://munin.projects.linpro.no/ticket/94 quit * juan The new version of rrdtool (1.2x) now uses truetype fonts and can smooth both the fonts and graphics. The graphs were much clearer before the update Hi. Thanks for your report - it has been forwarded upstream. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307997: munin-graph is a no-op if graph_strategy cgi
forwarded 307997 http://munin.projects.linpro.no/ticket/98 quit * Marc Haber munin-graph doesn't to anything if it detects graph_strategy cgi. This should be documented in the man page. Hi Marc, thanks for your report. The issue is forwarded upstream. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337320: munin-node: port_ plugin parsing of /proc/net/tcp6 is wrong
forwarded 337320 http://munin.projects.linpro.no/ticket/95 quit * John Bäckstrand Parsing of /proc/net/tcp6 by the port_ plugin is broken, most significant hex digit of port is stripped out. Hi, thanks for your report. The issue is now forwarded upstream. -- Tore Anderson
Bug#351436: Please make graph_width, graph_height and possibly others configurable per-node and/or per-server
forwarded 351436 http://munin.projects.linpro.no/ticket/96 forwarded 305917 http://munin.projects.linpro.no/ticket/97 * Andras Korn it'd be useful to be able to adjust the size of the graphs centrally. [...] Ps. and what about the nut plugin I submitted? :) Hi Andras, thanks for your reports and apologies for the late answer. I've now forwarded the issues upstream at the URLs above. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351720: tune2fs -O resize_inode
Package: e2fsprogs Severity: wishlist Hi. It would be really nice if you could add the resize inode with e2fsprogs, as online resizing is immensely useful, but sadly most distributions don't create file systems that are ready for it by default. The ext2resize suite appears to be unmaintained (RC bugs open for over a year), and its ext2prepare tool appears to create the resize inode incorrectly, see #348778. So it would be nice if this functionality would be available in e2fsprogs as well, which appears to be reasonably well-maintained. ;-) This wishlist could also be extended to adding ext2online-equivalent functionality to e2fsprogs as well. Even though it seems that this tool works correctly and is able to online-resize file systems without corrupting them, I must admit I fully trust only e2fsprogs when it comes to the integrity of my data... Cheers -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346387: Support for Xen as a subarch
* Tore Anderson I think that file is only used if ARCH=xen. Which is correct for all released versions of Xen, but the new implementation that eventually will be merged into the kernel sources use ARCH=i386 (or x86_64), and then you choose Xen-compatible when asked for Subarchitecture Type under Processor type and features in menuconfig. This sets CONFIG_X86_XEN=y. * Manoj Srivastava Have your tried make-kpkg with ARCH=xen? I think I see code that'll allowit to do the right thing. Hmm. I think we're talking past each other. I'll try to explain. When the Xen project started releasing kernel patches, they made Xen a completely separate architecture. To build it you needed ARCH=xen. All released versions of Xen use ARCH=xen, and make-kpkg are able to build packages of these kernels just fine. This bug report is not about those kernels, however. Now, the Xen people wanted to have their code accepted into Linus' tarball. However, the attitude of the people on LKML was something like: «Why do you need a completely separate arch/xen/ when 90% of the code is the same as in arch/i386/? Think about the code duplication and the maintenance nightmare it will be. We won't accept your patch before it improves on these issues.» So the Xen people, determined on getting their code into Linus' tree, went back to the drawing board and came up with a plan that should please the LKML people. Instead of having Xen a separate architecture, they made it a sub architecture of i386 (and x86_64, and in the future probably all other architectures Xen is ported to as well). In essence, that means that the arch/xen/ is removed, and all attempts to build the kernel with ARCH=xen will just fail with an error message such as (example of make oldconfig from the Mercurial pull of today): Makefile:449: /usr/src/linux-2.6-xen/arch/xen/Makefile: No such file or directory make: *** No rule to make target `/usr/src/linux-2.6-xen/arch/xen/Makefile'. Stop. Instead, all Xen-specific code are moved to arch/i386/mach-xen/ (for i386 at least). Now, in order to build a Xen kernel, you make your *config target of choice (using ARCH=i386), and when you are asked for Subarchitecture type (where most people select PC-compatible), you must instead select Xen-compatible. This sets CONFIG_X86_XEN=y. Then you can go on to build the kernel image as normal, still using ARCH=i386. But not bzImage, only vmlinuz - that's where make-kpkg currently fail. My bug report applies to these kernels only. To the best of my knowlegde, the only way to obtain such a kernel source is through the Mercurial repository. All released stable, alpha, beta, etc. versions are the old ARCH=xen way. But that will change as the Xen-as-subarch three reaches maturity; I doubt they want to maintain two separate source trees for very long, and the ARCH=xen way is a dead end due to the kernel maintainers' refusal to merge it. It seems the Xen-as-subarch tree is where the developers are at too, linux-2.6-xen.hg has been at 2.6.15 for some time, while xen-unstable.hg (where the most recent ARCH=xen code is found) is still at 2.6.12. I hope that cleared things up? :-) Kind regards -- Tore Anderson
Bug#348778: ext2prepare corrupts the file system
Package: ext2resize Version: 1.1.19-3 Severity: grave See attached log. After having run ext2prepare on an error-less filesystem, fsck starts complaining. File system corruption often leads to data loss and service downtime, so this is pretty bad... -- Tore Anderson debug.txt.gz Description: GNU Zip compressed data
Bug#346387: Support for Xen as a subarch
* Manoj Srivastava I see code in /usr/share/kernel-package/ruleset/arches/xen.mk to call and use vmlinuz insted of bzImage for kernel versions later than 2.5.41 -- is the version check not good enough? I think that file is only used if ARCH=xen. Which is correct for all released versions of Xen, but the new implementation that eventually will be merged into the kernel sources use ARCH=i386 (or x86_64), and then you choose Xen-compatible when asked for Subarchitecture Type under Processor type and features in menuconfig. This sets CONFIG_X86_XEN=y. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346544: acknowledged by developer (Fixed in 0.97-3)
reopen 346544 retitle 346544 another dash issue in update-grub severity 346544 minor quit * Kristian Edlund I believe that this bug and 346127 are the same bugs, at least the problem is the same and the solutions are similar. I'm closing this bug then, feel free to reopen it if you disagree. 0.97-3 made it complete sucsessfully, at least. But the fix uncovered another dash issue: [EMAIL PROTECTED] :) sudo /bin/dash /sbin/update-grub Searching for GRUB installation directory ... found: /boot/grub Testing for an existing GRUB menu.list file ... found: /boot/grub/menu.lst Searching for splash image ... none found, skipping ... [: 788: 9920060109: out of range [: 788: 9920060109: out of range Found kernel: /boot/vmlinuz-2.6.15-1-k7 Found kernel: /boot/vmlinuz-2.6.15-xen20060109 Updating /boot/grub/menu.lst ... done [EMAIL PROTECTED] :) If run under bash, the order changes, i.e. vmlinuz-2.6.15-xen20060109 is put as the first entry in menu.lst. But at least it generates a valid menu.lst using dash now. This should probably be fixed, too, in order to guarantee consistent behaviour. If you need it I can provide dash -x output, but I would think this issue is fairly easy to reproduce so I haven't bothered. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346387: Support for Xen as a subarch
* Manoj Srivastava I would be happy to add support, but I do not use Xen, and I can't test it. If you could tell me how you build Xen images manually (without kernel-package, just with the KConfig build system), and any suggestions on how one could distinguish between a normal i386 build and otherwise, I'll see what I can do to provide you with functionality for you to test. Hi Manoj. The only difference is that the generated kernel image is found in /usr/src/linux/vmlinuz instead of in /usr/src/linux/arch/i386/boot/bzImage. This is probably only because the kernel image doesn't need a boot sector, it's the Xen hypervisor (which isn't Linux at all) that are actually booted from Grub; the kernel image itself is in turn executed/booted from the Xen hypervisor, which has already done all the nasty stuff (bringing the CPU into protected mode, enabling additional CPUs, etc). Anyway, when I run make-kpkg I see that it attempts to do make the bzImage target, which is just a stub when CONFIG_X86_XEN=y is set, and does nothing (successfully). What is necessary is to make the vmlinuz target (or vmlinux for that matter), which will create the kernel image. When I build the kernels I actually use make-kpkg, but I build vmlinuz manually and then fool make-kpkg a bit with a symlink from bzImage. My small script for doing so is like this: REV=`date +%Y%m%d` make vmlinuz EXTRAVERSION=-xen$REV ln -sf ../../../vmlinuz arch/i386/boot/bzImage make-kpkg --initrd --rootcmd fakeroot --revision $REV --append-to-version -xen$REV --stem linux kernel_image ...which builds a linux-image.deb which works perfectly. So it's just a matter of figuring out when to use vmlinuz instead of bzImage. Maybe just grepping for CONFIG_X86_XEN=y in .config is adequate, but I don't think that will work with ia64 or x86_64 and I would assume you want a generic solution. Maybe simply a --use-vmlinuz-instead-of-bzImage command line option would suffice. In case you want to play around with this yourself and haven't used Mercurial before I'll include an ultra-concise guide to getting the Xen-as-subarch source tree here: apt-get install mercurial mkdir /usr/src/linux-2.6-xen cd /usr/src/linux-2.6-xen hg init . echo $'[paths]\ndefault = http://xenbits.xensource.com/linux-2.6-xen.hg' .hg/hgrc hg pull -u Kind regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346511: ext3 online resizing doesn't work
Package: linux-2.6 Version: 2.6.15-1 I can't get online resizing of ext3 to work. The kernel spits out EXT3-fs: Unrecognized mount option resize=1572864 or missing value when I try to remount the filesystem, supplying the resize option. Documentation/filesystems/ext3.txt says it should be there, and from what I can understand of fs/ext3/super.c and its parse_options() the resize option is supposed to be understood by the kernel. Am I doing something wrong? I have created the file system using mkfs -E resize. Resizing JFS (using the exact same procedure) works just fine. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346511: ext3 online resizing doesn't work
* Tore Anderson
I can't get online resizing of ext3 to work.
After some more debugging it seems that the resize option isn't
correctly parsed by fs/ext3/super.c. Patch attached. However, I'm not
too sure if it is correct, right now my mount process is hanging in
blocking I/O state, and there's almost no disk activity. I started it
two and a half hour ago... The only thing the kernel had to say about
it was:
EXT3-fs warning (device dm-3): ext3_group_extend: will only finish group
(4194305 blocks, 1 new)
I suspect ext2online(8) is the only supported way of doing online
resizing, and that the resize= mount option is intentionally broken
because of that. Perhaps it's a relic from the early days of the code
in question... But I don't know.
--
Tore Anderson
Fix parsing of the resize=nblocks ext3 (re)mount option.
Signed-off-by: Tore Anderson [EMAIL PROTECTED]
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 4e67306..1eb16f5 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -681,8 +681,8 @@ static match_table_t tokens = {
{Opt_quota, quota},
{Opt_usrquota, usrquota},
{Opt_barrier, barrier=%u},
+ {Opt_resize, resize=%u},
{Opt_err, NULL},
- {Opt_resize, resize},
};
static unsigned long get_sb_block(void **data)
Bug#346511: ext3 online resizing doesn't work
* Bastian Blank Stock linux does not support online resizing of ext3. It does (since 2.6.10). I've successfully extended mounted ext3 file systems using ext2online from ext2resize 1.1.19-3 on an unmodified 2.6.15-1-k7. However the more I've looked into it, the more certain I've become that it is Documentation/filesystems/ext3.txt that is incorrect - the resize=nblocks mount option is probably disabled due to the fact that it's not working properly; using ext2online(8) is currently the only way to do it. Or so it seems to me. I just submitted a patch upstream that corrects the documentation, so it's probably going to be fixed in the next upstream release, but it's fine by me to close the bug already now anyway. Kind regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346580: mke2fs -O resize_inode fails on large block devices ( 15GB)
Package: e2fsprogs Version: 1.38+1.39-WIP-2005.12.31-1 Severity: minor [EMAIL PROTECTED] :) sudo mke2fs -O resize_inode -j /dev/pride/rt mke2fs 1.39-WIP (31-Dec-2005) /dev/pride/rt: Too many reserved group descriptor blocks while setting up superblock [EMAIL PROTECTED] :( The block device in question is exactly 20GB large. It seems I cannot use -O resize_inode on block devices larger than 15GB, where it reserves space for growing the filesystem up to 15TB. If there is a limitation on how large the resize_inode can be, mkfs should probably just reserve as much as it can and leave it at that if the default size exceeds the limitation. It attempts to reserve space so the filesystem can grow to 1024 times its initial size, right? By the way, -O resize_inode isn't mentioned in the manual page. I've attached a suggested patch. Kind regards -- Tore Anderson diff -ru e2fsprogs-1.38+1.39-WIP-2005.12.31/misc/mke2fs.8.in foo/misc/mke2fs.8.in --- e2fsprogs-1.38+1.39-WIP-2005.12.31/misc/mke2fs.8.in 2006-01-07 03:26:38.0 +0100 +++ foo/misc/mke2fs.8.in 2006-01-08 23:52:15.0 +0100 @@ -375,6 +375,16 @@ @[EMAIL PROTECTED] be created with the same @[EMAIL PROTECTED] size as the filesystems that will be using it. .TP +.B resize_inode +Reserve space so the block group descriptor table may grow in the future. +Useful for online resizing using the +.B ext2online +tool. By default it attempts to reserve enough space so that the +filesystem may grow to 1024 times its initial size. You may change that +using +.B -E resize +though. +.TP .B sparse_super Create a filesystem with fewer superblock backup copies (saves space on large filesystems). @@ -458,4 +468,5 @@ .BR badblocks (8), .BR dumpe2fs (8), .BR e2fsck (8), -.BR tune2fs (8) +.BR tune2fs (8), +.BR ext2online (8)
Bug#346585: mke2fs asks for y/n in the it_IT locale, but expects s/n
Package: e2fsprogs Severity: minor Version: 1.38+1.39-WIP-2005.12.31-1 Tags: l10n patch [EMAIL PROTECTED] :) sudo mke2fs /dev/pride/rt 25G mke2fs 1.39-WIP (31-Dec-2005) mke2fs: Il filesystem è più grande della dimensione apparente del device. Procedere comunque? (y,n) y [EMAIL PROTECTED] :( sudo mke2fs /dev/pride/rt 25G mke2fs 1.39-WIP (31-Dec-2005) mke2fs: Il filesystem è più grande della dimensione apparente del device. Procedere comunque? (y,n) s Etichetta del filesystem= Tipo SO: Linux [...] The Italian translation of «yes» is «sì», and obviously mke2fs expects «s» as the answer indicating agreement. I've attached a patch that corrects the translation. I'm not 100% sure if it's complete, though, as I see the string in the binary file po/it.gmo as well. But I assume that file is generated from po/it.po? (I've never used gettext.) Kind regards -- Tore Anderson diff -ru e2fsprogs-1.38+1.39-WIP-2005.12.31/po/it.po e2fsprogs-1.38+1.39-WIP-2005.12.31-tore/po/it.po --- e2fsprogs-1.38+1.39-WIP-2005.12.31/po/it.po 2006-01-07 03:26:38.0 +0100 +++ e2fsprogs-1.38+1.39-WIP-2005.12.31-tore/po/it.po 2006-01-09 00:13:10.0 +0100 @@ -4139,7 +4139,7 @@ #: misc/util.c:72 msgid Proceed anyway? (y,n) -msgstr Procedere comunque? (y,n) +msgstr Procedere comunque? (s,n) #: misc/util.c:93 #, c-format
Bug#346585: Duplicate, merge with #316497
tags 316497 +patch merge 346585 316497 quit Why is it I always overlook the bug I'm going to duplicate while looking through the bug list? Sorry about the noise, Ted. Oh well. At least you have got a patch now... :-) -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
