Bug#291351: [Pkg-nagios-devel] Bug#291351: nagios-text: CGI interface displays no data, but nagios functioning correctly
hi tristan, On Thu, Jan 20, 2005 at 10:37:24AM +0200, Tristan Seligmann wrote: > Package: nagios-text > Version: 2:1.3-0+pre6 > Severity: normal could you try with the latest version (2:1.3-cvs.20050116-1) of nagios out of unstable? there were a number of cleanups and bugfixes in that release. otherwise, any error messages you could find in nagios.log or the apache error log would be helpful in figuring out what's wrong. sean -- signature.asc Description: Digital signature
Bug#291945: mysql-server: build against openssl?
Package: mysql-server Version: 4.0.18-5 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 is there any reason mysql is being built without openssl support? from debian/rules: --without-openssl \ sean - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages mysql-server depends on: ii adduser 3.52 Add and remove users and groups ii debconf 1.4.22 Debian configuration management sy ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdbi-perl 1.40-1 The Perl5 Database Interface by Ti ii libgcc1 1:3.4.1-7GCC support library ii libmysqlclient124.0.18-5 mysql database client library ii libssl0.9.7 0.9.7d-1 SSL shared libraries ii libstdc++5 1:3.3.4-9The GNU Standard C++ Library v3 ii libwrap07.6-ipv6.1-3 Wietse Venema's TCP wrappers libra ii mysql-client4.0.18-5 mysql database client binaries ii passwd 1:4.0.3-26 Change and administer password and ii perl5.8.4-4 Larry Wall's Practical Extraction ii psmisc 21.4-1 Utilities that use the proc filesy ii zlib1g 1:1.2.2-3compression library - runtime - -- debconf information excluded -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB9I9ZynjLPm522B0RAjgcAJ9rbiasbZ/DDUiN1W4D50gap3cmQgCdH3pE nfrVh4IM8n/dQsAIyyr36lo= =C3cj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291945: mysql-server: build against openssl?
On Mon, Jan 24, 2005 at 10:33:06AM +0100, Christian Hammers wrote: > Yes, the OpenSSL licence was not compatible with the current MySQL licence > and MySQL declared that they do not plan to continue OpenSSL support anyway. > Most probably they go for GnuTLS somewhen. aha, i was wondering about that. in the online comments with the ssl-related mysql docs, i saw numerous people mentioning issues regarding redistributing ssl-enabled binaries. the reason for asking this originally is i'd like to add support for mysql+ssl to my dbconfig-common project. anyway, if they do opt for gnutls support, i'd consider that sufficient for my needs. i guess we can just leave it as a wontfix bug until then... sean -- signature.asc Description: Digital signature
Bug#292406: [Pkg-nagios-devel] Bug#292406: nagios-mysql: mysql error: Column 'last_log_rotation' cannot be null
close 292406 thanks hi brian, On Thu, Jan 27, 2005 at 08:21:34AM +1100, Brian May wrote: > ERROR 1048: Column 'last_log_rotation' cannot be null this is actually a bug in mysql server, and is fixed in version 4.0.23-3. sean -- signature.asc Description: Digital signature
Bug#340829: Security-Issue in Cacti
tags 340829 unreproducible security moreinfo notfound 340829 0.8.6f-1 thanks hi ulrich, On Sat, Nov 26, 2005 at 09:31:38AM +0100, Ulrich Huber wrote: > Package: Cacti > Version; 0.8.6c-7 > > According to the Cacti-Doku an a Forum Entry, there is a security hole (and > yes, it already happend to me on one of my machines...), which still exists > on the debian Version, but seems to be fixed in a newer Cacti-Release. So > please include the patch... could you provide a link to the forum entry? as far as i know the three related security holes are fixed in 0.8.6c-7sarge2, which was uploaded to sarge's security updates branch some time ago. are you sure you're running 0.8.6c-7 and not 0.8.6c-7sarge2? if so, i think that's the problem (and i'm hoping so...). > http://bugs.cacti.net/view.php?id=623 will tell you about the bug and the > way intruders are exploiting it. again, afaict the fixes have already been included. if it is still exploitable, could you send me some example log entry from your your web servers' access logs, so i can reproduce this myself? thanks, sean signature.asc Description: Digital signature
Bug#340726: [Pkg-nagios-devel] Bug#340726: nsca: please provide a way to install send_nsca without nagios + dependencies
hey stephen, On Fri, Nov 25, 2005 at 12:11:10PM +, Stephen Gran wrote: > split send_nsca and nsca into two packages (which seems silly, as they > would have one binary apiece, but is not unprecedented), or relax the > depends to a recommends. I think the first is actually a better option > as admins installing nsca will actually want it to be useful, and nsca > itself is only useful on the nagios host. i recently took over this package and have taken the second route, at least initially. so, if you install from etch/sid you should be able to pull in nsca w/out everything else. in the future, i may split them into two packages, or somehow make it more easily configurable for satellite/distributed install environments. sean signature.asc Description: Digital signature
Bug#337886: fixed upstream, waiting for release/patch
just fyi, i've been notified by the upstream bts that the issue will be fixed and released in 0.8.6h. i'll include the fix when this version is released, or when an official patch is released (whichever comes first). sean -- signature.asc Description: Digital signature
Bug#341028: /usr/sbin/dbconfig-load-include: dbconfig-load-include does not work as advertised
On Sun, Nov 27, 2005 at 10:27:02PM +0100, Thijs Kinkhorst wrote: > 1) the -f (format) option is listed to default to 'sh', but it doesn't. > When omitting the -f option the program yields "error: you must specify a > format!". Which makes sense to me, so I think just the mention of the > default should be dropped. done. i've changed "default: sh" to "must be specified", as i agree that makes a little more sense. > 2) the short options -d, -s, -p, -u, -P and -t do not work. The man page > and online help give: > dbconfig-load-include [-hv] [-a] [-d [varname]] [-u [varname]] [-p > [varname]] [-s [varname]] [-P [varname]] [-t [varname]] -f format infile > but here's what happens with e.g. -t: > $ dbconfig-load-include -t dbms -f php /etc/package/config.php > unable to read input file dbms > $ dbconfig-load-include -t=dbms -f php /etc/package/config.php > Parse error: parse error, unexpected '=', expecting T_VARIABLE or '$' > in - on line 21 > $ dbconfig-load-include --dbtype dbms -f php /etc/package/config.php > unable to read input file dbms > $ dbconfig-load-include --dbtype=dbms -f php /etc/package/config.php > dbc_dbtype='mysql'; > So only the last invocation works, but this way of calling is advertised > nowhere. looks like some getopt funkiness, i'll take a look to see if i can find what is causing it... sean signature.asc Description: Digital signature
Bug#341028: /usr/sbin/dbconfig-load-include: dbconfig-load-include does not work as advertised
having now looked at the getopt issue: > 2) the short options -d, -s, -p, -u, -P and -t do not work. The man page > and online help give: > dbconfig-load-include [-hv] [-a] [-d [varname]] [-u [varname]] [-p > [varname]] [-s [varname]] [-P [varname]] [-t [varname]] -f format infile > but here's what happens with e.g. -t: > $ dbconfig-load-include -t dbms -f php /etc/package/config.php > unable to read input file dbms > $ dbconfig-load-include -t=dbms -f php /etc/package/config.php > Parse error: parse error, unexpected '=', expecting T_VARIABLE or '$' > in - on line 21 > $ dbconfig-load-include --dbtype dbms -f php /etc/package/config.php > unable to read input file dbms > $ dbconfig-load-include --dbtype=dbms -f php /etc/package/config.php > dbc_dbtype='mysql'; > So only the last invocation works, but this way of calling is advertised > nowhere. so it seems the way getopt(1) handles cmdline arguments is that if you have an argument that takes an optional argument (like -t [varname]), then the argument must immediately follow the cmdline flag (-t[varname]). some simple testing shows that this works, afaict. i'll commit changes to CVS right now to ammend the documentation. sean -- signature.asc Description: Digital signature
Bug#341601: postfix-gld: please consider using dbconfig-common for database setup
Package: postfix-gld Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, please consider using dbconfig-common for configuring the database-related aspects during installation of postfix-gld. dbconfig-common can: * support mysql and postgresql based applications * create databases and database users * access local or remote databases * upgrade/modify databases when upstream changes database structure * remove databases and database users * generate config files in many formats with the database info * import configs from packages previously managing databases on their own * prompt users with a set of normalized, pre-translated questions * handle failures gracefully, with an option to retry. * do all the hard work automatically * work for package maintainers with little effort on their part * work for local admins with little effort on their part * comply with an agreed upon set of standards for behaviour * do absolutely nothing if it is the whim of the local admin * perform all operations from within the standard flow of debian package maintenance (no additional skill is required of the local admin) you can find more information about dbconfig-common (including docs and example packages) at: http://people.debian.org/~seanius/policy/dbconfig-common.html/ thanks sean - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDjyYgynjLPm522B0RAvv8AJ4wQoLM7r9kcKpT5v4r7y8rIwbj2gCggBEM MMLxXyqwwbGF8rV03s+f0D4= =fyJv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341748: ITP: nagios2 -- A host/service/network monitoring and management system
Package: wnpp Severity: wishlist Owner: Sean Finney <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (explanation for why there needs to be a nagios2 given after the blurb) Package name: nagios2 Version : 2.0 (when released) Upstream Author : Ethan Galstad URL : http://www.nagios.org/ License : GPL Description : A host/service/network monitoring and management system Nagios is a replacement of the Netsaint project. It accept and uses the previous Netsaint modules transparently. . Nagios is a host/service/network monitoring and management system. It has the following features: . o Monitoring of network services (via TCP port, SMTP, POP3, HTTP, NNTP, PING, etc.) o Plugin interface to allow for user-developed service checks o Contact notifications when problems occur and get resolved (via email, pager, or user-defined method) o Ability to define event handlers to be run during service or host events (for proactive problem resolution) o Web output (current status, notifications, problem history, log file, etc.) . Nagios was written in C and is designed to be easy to understand and modify to fit your own needs. . This package contains the next-generation version of the nagios daemon. If you want to install nagios and do not need MySQL or PostgreSQL support, you should install this package. some skeptics may be asking "why do we need a nagios2? why can't we have just one version of nagios in debian?". the answer is that we in fact already have 3 different versions of nagios, one with standard file-based support, a mysql version, and a pgsql version (which are differentiated at compile time). nagios2 does not currently have db support, but will very likely through add-on modules at a future date/time. because this would break existing installations that use the db support, there will be a certain period where nagios2 and nagios co-exist in the archives. after transitional support has been worked out, it will replace the standard file flavor of nagios, and as db support is added in the other two versions will disappear as well. In the end, i aim to have a single "nagios" package, though it will probably take a bit for this to materialize. i'll shortly be importing an initial version of nagios2 into the nagios alioth project cvs archives. if anyone is interested in helping maintain this (or other nagios related packages), please contact me privately as i can always use some assistance! sean -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDkIWWynjLPm522B0RAgvuAJ0c9o5yL8OBkXxceebOxyydFiD0swCeO4Xr Yg1/K2tcct4wTisehqF94ow= =i3JZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341819: libmysqlclient14: shlibs need to be bumped to require >=4.1.14-3
hi andreas, On Sat, Dec 03, 2005 at 01:08:17PM +0100, Andreas Metzler wrote: > Package: libmysqlclient14 > Version: 4.1.14-3 > Severity: minor > > This change to debian/rules should do the trick: > -dh_makeshlibs -a > +dh_makeshlibs -a -V'libmysqlclient14 (>=4.1.14-3)' i think this makes sense, but i'll leave it to christian to decide, since he's the one who's taken point on the versioning. sean signature.asc Description: Digital signature
Bug#341958: dbconfig-common: Support for table prefix
hi thijs, On Sun, Dec 04, 2005 at 02:05:01PM +0100, Thijs Kinkhorst wrote: > I'm working on adding dbconfig-common to my package. One thing I'm > encountering is that it allows to specify a table prefix which defaults > to phpbb2, so your tables will be of the format phpbb2_users etc. We > currently offer this as a debconf question on installation. In my > perception this is a common option for webapps, right? i could see it as a possible benefit for multiple webapps using the same database, yes. iirc phpgw has a similar feature. > Is it currently possible to have dbconfig-common handle this aswell? If > it does, I couldn't find it. If it doesn't, what are the chances of this > being added? unfortunately, it doesn't currently. the problem is that dbconfig-common as it stands is agnostic to the contents of the databases that it creates. that is, basically, it creates the users/databases, and then leaves it to the maintainer-provided sql/script to create and populate the tables. the benefit of this is that things are much simpler and less prone to failure/bugs. the drawback, obviously, is that there isn't a way to do this. however, i am open to ideas for how this could be implmented. here's some thoughts off the top of my head: at the very least, dbconfig-common could hold the common debconf template, so that multiple packages could benefit from having the text pre-translated. perhaps later dbc could be extended to handle the prompting logic so that packages needing/wanting this could set another dbc_foo variable in the maintscripts which would trigger the extra prompting logic, and the result could get stored in the packages' dbc config file. it would still be the packagers' responsibility to ensure that the table prefixes are correctly used when creating the tables, which means that the simple sql-file install method is out and they would have to use the script method for installing the db, but it's an improvement, anyway. btw: how is phpbb currently handling this? i think as a final step, perhaps dbc could do something like 's/create table /create table $dbc_tbl_prefix/' on static sql files, but this seems a little fragile to me so i'd only want to do it after being able to do the other stuff reliably... and even then i'd still be a little anxious about it. what do you think? sean -- signature.asc Description: Digital signature
Bug#341705: more information?
tags 341705 unreproducible moreinfo thanks hi olaf, sorry there hasn't been a response sooner, christian's on vacation and i just realized that i wasn't subscribed to the bug feed for mysql-dfsg-5.0. anyway, i'll need some more information before we can do anything: - does it crash on certain queries, or other conditions? - does it crash immediately after starting? - what apps are using the database? - straces, core dumps, log entries, sql queries etc - is the problem present in the latest version in unstable? sean signature.asc Description: Digital signature
Bug#323876: closing old bug
close 323876 thanks as promised in previous followup... signature.asc Description: Digital signature
Bug#341705: more information?
hi olaf, On Mon, Dec 05, 2005 at 05:22:48PM +0100, Olaf van der Spek wrote: > See for example http://bugs.mysql.com/bug.php?id=13545 > The server is running custom game lobby servers (http://xwis.net/), > scripts and dynamic web pages and it kept restarting within a minute. > I can't tell for sure what caused this specific issue or whether it's > fixed in the version in unstable, but 5.0.13 is pre-GA and two months > old, 5.0.16 is GA and at least one server crashing issue has been solved. well, if you're not able/willing to try the version in unstable, then i suggest that we do the following: - downgrade the severity to "important". - mark it as notfound in 5.0.16 - wait for 5.0.16 to make it to testing. what do you say? sean signature.asc Description: Digital signature
Bug#341705: more information?
hi, On Mon, Dec 05, 2005 at 05:52:22PM +0100, Olaf van der Spek wrote: > >well, if you're not able/willing to try the version in unstable, then > >i suggest that we do the following: > > I can confirm that the linked reduced test case does not crash in > 5.0.16-Debian_1. okay, i wasn't sure if the bugreport in question was in fact the same problem, or if it's an unrelated one. i've noticed that mysql seems to crash quite a bit :) > >- downgrade the severity to "important". > > Why? > > >- mark it as notfound in 5.0.16 > > If I didn't test it, how can you claim the notfound? well, we have to do at least one of the above if we ever want something to migrate into testing. > >- wait for 5.0.16 to make it to testing. > > But for how long? beats me :) sean signature.asc Description: Digital signature
Bug#341705: more information?
notfound 341705 5.0.16-1 thanks On Mon, Dec 05, 2005 at 06:32:58PM +0100, Olaf van der Spek wrote: > If/when binutils gets fixed it's at least another 10 days. > What about testing-proposed-updates? honestly, it's more work/time than i'm willing to give, and i'm reluctant to put work into a problem that will eventually solve itself. unfortunately, christian's out for the next week, so i can't know what his take on it is. if you feel strong enough about it to prepare an update for tpu on your own (where the fix is backported as a dpatch file), i'd be willing to look at it though. sean -- signature.asc Description: Digital signature
Bug#341705: more information?
On Mon, Dec 05, 2005 at 08:04:41PM +0100, Olaf van der Spek wrote: > Isn't it possible (and much easier) to compile 5.0.16 completely in a > testing dev environment and upload that? hrm, i didn't think that you could do that with tpu (uploading a new upstream version). my impression, and the developers' reference seems to agree with this[1], is that tpu is only for minimal backported fixes. that said, if you can get someone from the release team to sign off on such an upload, i'll happily do it when i have a chance. sean [1] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-t-p-u -- signature.asc Description: Digital signature
Bug#341705: more information?
On Mon, Dec 05, 2005 at 03:58:47PM -0800, Steve Langasek wrote: > > that said, if you can get someone from the release team to sign > > off on such an upload, i'll happily do it when i have a chance. > > New upstream versions for RC bugfixes are allowed via t-p-u, yes. okay, cool--thanks. i'll see about preparing a testing build of 5.0.16 next time my build box is powered up. sean signature.asc Description: Digital signature
Bug#341705: more information?
hi, while in a lecture this morning i found my thoughts travelling back to this bug report for some reason and... On Mon, Dec 05, 2005 at 03:58:47PM -0800, Steve Langasek wrote: > New upstream versions for RC bugfixes are allowed via t-p-u, yes. this may stem from my unfamiliarity with tpu: how will the version of 5.0.16 from unstable ever make it to testing if the version in tpu is the same? i'm just a bit concerned because we'd have two packages with the same version but different dependencies, which seems like a Bad Idea in general. i had the impression from the developers' reference that the versions must be testing < tpu < unstable, so how would we work that out? would we essentially be committing to tracking a tpu branch (5.0.16etchN, which is > unstable) until the next upstream release? sean -- signature.asc Description: Digital signature
Bug#342237: apt: where is the archive keyring? not /usr/share/keyrings/debian-archive-keyring.gpg
Package: apt
Version: 0.6.43
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
copelandia[~]14:24:26$ sudo apt-key update
ERROR: Can't find the archive-keyring
Is the debian-keyring package installed?
copelandia[~]14:24:28$ sudo apt-get install debian-keyring
Reading package lists... Done
Building dependency tree... Done
debian-keyring is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 196 not upgraded.
copelandia[~]14:24:56$ sudo strace apt-key update 2>&1 | grep keyring | grep
stat
stat("/usr/share/keyrings/debian-archive-keyring.gpg", 0x7ff3dee0) = -1
ENOENT (No such file or directory)
should that be /usr/share/apt/debian-archive.gpg?
copelandia[~]14:26:46$ sudo ln -s /usr/share/apt/debian-archive.gpg
/usr/share/keyrings/debian-archive-keyring.gpg
copelandia[~]14:27:07$ sudo apt-key update
gpg: keyring `/etc/apt/trusted.gpg' created
gpg: /etc/apt/trustdb.gpg: trustdb created
gpg: key 1DB114E0: public key "Debian Archive Automatic Signing Key
(2004) <[EMAIL PROTECTED]>" imported
gpg: key 4F368D5D: public key "Debian Archive Automatic Signing Key
(2005) <[EMAIL PROTECTED]>" imported
gpg: key B5F5BBED: public key "Debian AMD64 Archive Key
" imported
gpg: Total number processed: 3
gpg: imported: 3 (RSA: 1)
gpg: no ultimately trusted keys found
sean
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFDlZKBynjLPm522B0RAlsWAJ9V2GSW4ruRwL0/upTcE5xh3fqjxQCfVEPa
kMpqu7oedvt9MCq+7QHbOHw=
=siHW
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342244: mysql-dfsg-5.0: FTBFS on hppa
On Tue, Dec 06, 2005 at 03:33:52PM +0100, Frank Küster wrote: > CRUFT BEGIN > /usr/bin/fakeroot: line 152: 24322 Trace/breakpoint trap > FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" "$@" > Build killed with signal 15 after 150 minutes of inactivity > ** > Build finished at 20051203-0616 > FAILED [dpkg-buildpackage died] > > Don't know whether this is a problem with fakeroot or with the "CRUFT" > in the Makefile. blech. well, it could be any of the following commands in our list of CRUFT: @echo "CRUFT BEGIN" @find -type l -print0 | xargs --no-run-if-empty -0 rm -v @find -name .deps -type d -print0 | xargs --no-run-if-empty -0 rm -rfv @rm -vrf ndb/docs/.doxy* ndb/docs/*html ndb/docs/*pdf innobase/autom4te.cache @for i in \ readline/Makefile \ sql-bench/Makefile \ scripts/make_win_binary_distribution \ scripts/mysql_explain_log \ scripts/mysql_tableinfo \ scripts/mysqlbug \ sql/lex_hash.h \ strings/ctype_autoconf.c \ config.log \ config.cache \ ; \ do \ rm -vf $$i; \ done @echo "CRUFT END" none of these should endlessly loop. if faulty hardware/disk is suspect, the find jobs might be taking an extraordinary amount of time as a result... i can see a way to optimise the cleanups on the .deps directory (passing -prune to find) but it seems orthogonal to the problem at hand. is it worth uploading a new version with the "@"'s removed, or is there some other way to investigate what's going on? sean signature.asc Description: Digital signature
Bug#342244: mysql-dfsg-5.0: FTBFS on hppa
hi -admin and -devel, executive summary: mysterious and unreproducible ftbfs for mysql, and perhaps other packages on the hppa architecture. a faulty buildd (sarti) is suspected, but afaict all requests for information remain unanswered. i'm suspecting hardware problems, as for mysql this is not the first such ftbfs[1]. originally, a similarly mysterious error occurred where the build didn't even start because installing tetex-bin failed. Frank Küster followed up[2] with debian-hppa as well as debian-admin about the problem, but afaik recieved no response. now, mysql is failing during the execution of debian/rules, in a chunk of code doing no more than a find/xargs/rm[3]. the buildd reports that the job failed do to a lack of activity for more than 150 minutes[4]. On Tue, Dec 06, 2005 at 04:56:58PM +0100, Frank Küster wrote: > I have asked ryan murray and the hppa list about this, but never > received an answer. I don't know whether the problem magically solved > itself (which would again point to a hardware problem) or whether some > admin acted. It would be interesting to find out why the buildd tried > again to build the package after the last one failed - maybe this gives > some insight who did what why when. it would be nice if someone could comment on the matter. looking back in the archives for the hppa list, i see at least one other unrelated post[5] indicating the same problem for multiple other packages, also unanswered so far. this mail was only sent yesterday (20051205) though. however, the poster does point out that the failing packages build just fine on other hppa machines. in the meantime, i'm forwarding this on to d-d (and cc'ing d-a, but not d-hppa as it won't do more good than what's already been done). as much as i hate to stoop to this level, i find often making a public fuss about things is the quickest way to get things going, and i don't know what else can be done. all flames/tar/feathers can be sent my way for having done so and i apologize for having done so if i am in fact totally off-base on my assumptions. sean [1] http://bugs.debian.org/340279 [2] http://lists.debian.org/debian-hppa/2005/11/msg00017.html [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342244 [4] http://buildd.debian.org/fetch.php?&pkg=mysql-dfsg-5.0&ver=5.0.16-1&arch=hppa&stamp=1133590988&file=log&as=raw [5] http://lists.debian.org/debian-hppa/2005/12/msg00012.html signature.asc Description: Digital signature
Bug#341705: more information?
hi steve, olaf, On Tue, Dec 06, 2005 at 01:30:23AM -0800, Steve Langasek wrote: > Yeah, it simply won't work. You'd need to give this build a distinguishing > version number that's < the version in unstable; perhaps 5.0.16-0+etch1. > > I'd advise against giving it a different upstream version number. i've created an etch pbuilder chroot and produced some debs: http://people.debian.org/~seanius/mysql/etch/ i haven't verified anything about these other than the fact that they built sucessfully, so a once-over would be appreciated. after i've heard back from the first brave soul to test them out that there are no problems, i'll go ahead and send them to tpu if there are no objections. as steve suggested, i've given them a 5.0.16-0+etch1 version so they will immediately upgrade to the versions currently in sid. they are based off of what's in svn as 5.0.16-2 but not yet released (which is just the initial upstream release + a documentation fix). christian: i'll follow up privately when you get back to decide how this should be represented in svn. sean -- signature.asc Description: Digital signature
Bug#341705: more information?
hi christian, On Wed, Dec 07, 2005 at 11:36:47AM +0100, Christian Hammers wrote: > Feel free to upload this to t-p-u. > I created an etch-5.0 branch for this based on the current 5.0 branch: > svn+ssh://svn.debian.org/svn/mysql-dfsg-41/branches/etch-5.0 ok, i've merged the changes (just lines in the changelog, actually) into this tree. however, i'm still waiting to hear back from someone that it works before i make the upload. sean -- signature.asc Description: Digital signature
Bug#340841: me too report: ktorrent locks and hangs while downloading
Package: ktorrent Version: 1.1-1 Followup-For: Bug #340841 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, i'm having this problem as well. i get about half a MB into my download, and the program hangs to the point that it does not repaint itself when it gets dragged to a new desktop or something covers it temporarily. the strange thing is it doesn't seem to have much to do with the data that i'm downloading, as in sometimes it will hang after half a meg, other times after a meg and half, other times it just keeps on going for the exact same chunk of data. sean - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages ktorrent depends on: ii kdelibs4c24:3.4.2-4 core libraries for all KDE applica ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libaudio2 1.7-3 The Network Audio System (NAS). (s ii libc6 2.3.5-8GNU C Library: Shared libraries an ii libfam0c102 [libfam0] 2.7.0-7client library to control the FAM ii libfontconfig12.3.2-1generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-5 GCC support library ii libice6 6.8.2.dfsg.1-7 Inter-Client Exchange library ii libidn11 0.5.18-1 GNU libidn library, implementation ii libjpeg62 6b-10 The Independent JPEG Group's JPEG ii libpcre3 6.4-1.0.1 Perl 5 Compatible Regular Expressi ii libpng12-01.2.8rel-5 PNG library - runtime ii libqt3-mt 3:3.3.5-1 Qt GUI Library (Threaded runtime v ii libsm66.8.2.dfsg.1-7 X Window System Session Management ii libstdc++64.0.2-5The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-7 X Window System protocol client li ii libxcursor1 1.1.3-1X cursor management library ii libxext6 6.8.2.dfsg.1-7 X Window System miscellaneous exte ii libxft2 2.1.7-1FreeType-based font drawing librar ii libxi66.8.2.dfsg.1-7 X Window System Input extension li ii libxinerama1 6.8.2.dfsg.1-7 X Window System multi-head display ii libxrandr26.8.2.dfsg.1-7 X Window System Resize, Rotate and ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt66.8.2.dfsg.1-7 X Toolkit Intrinsics ii xlibs 6.8.2.dfsg.1-7 X Window System client libraries m ii zlib1g1:1.2.3-8 compression library - runtime ktorrent recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmzJJynjLPm522B0RAr27AJ9cUAgedpnF7BsBPHLoChMtRf+sdQCfZITe cyu6rq610XFHB3EoCr3V5M8= =Gq9g -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343683: [Pkg-nagios-devel] Bug#343683: nagios-mysql: New install scripts do not reask for the passwords when running dpkg-reconfigure
hi farzad, On Sat, Dec 17, 2005 at 07:38:01AM +0100, Farzad FARID wrote: > I let dbconfig-commong handle the MySQL configuration, but made a mistake > when entering the nagios database's password. I ran dpkg-reconfigure, but > it never reasks for the database password again, so I can't correct the > problem. > > In fact, I even have to select 'retry' after the config failure to make the > script ask me for the MySQL main password again, which it doesn't do on the > first run. interesting. i'll have to look into why it doesn't prompt for the password a second time, but won't have time for the next week or so. in the meantime, be aware that you can also edit /etc/dbconfig-common/nagios-mysql.conf, which is where the configuration information is stored. or, you can edit the nagios configuration manually of course, but... that would be ruining all the fun of an automatic system :) sean signature.asc Description: Digital signature
Bug#343691: Upgrade to 0.8.6g-3 overwrites /etc/cacti/debian.php will null values
hi jesse, On Sat, Dec 17, 2005 at 02:31:15AM -0700, Jesse Molina wrote: > During the upgrade, I recall being prompted about the new > dbconfig-common option. I selected "n" for No. However, the file was > cleared, rendering Cacti disfunctional. I didn't notice until today > that polling had stopped. I noticed when I saw an error message while > trying to review stats for the week. hrm.. well it shouldn't be doing that. when i have a chance (which will be in a few days) i'll try to see why dbconfig-common is doing that. sean signature.asc Description: Digital signature
Bug#337236: [Pkg-nagios-devel] Bug#337236: nagios-common: Change defaults from somehost to localhost, etc
hi olaf, On Thu, Nov 03, 2005 at 02:42:09PM +0100, Olaf van der Spek wrote: > /etc/nagios/resource.cfg: > #xsddb_host=somehost > #xsddb_port=someport > #xsddb_database=somedatabase > #xsddb_username=someuser > #xsddb_password=somepassword > > Could you change this to localhost, 3306, nagios, nagios? > That would make configuration easier. that seems fairly reasonable, makes less typing for the admin in many cases :) > Also, what's the status on the automatic DB configuration? i took a stab at bringing in dbconfig-common, but hit a small snag because the credentials have to be provided in like 8 different places with different variable names. i think i can overcome this by either augmenting dbconfig-common (which i also maintain) or using some other novel hack, but haven't revisited trying to do so in a couple months. on a positive note, now that nagios-plugins is under pkg-nagios control we can move the check_nagios_db plugins into the package officially, and modify them to load credentials out of a config file, too, meaning much cleaner and more comprehensive support once it's in place. sean -- signature.asc Description: Digital signature
Bug#337886: cacti: No Graphs Listed in 'Graph Management'
hi jason, On Mon, Nov 07, 2005 at 01:38:57PM +1100, Jason Thomas wrote: > The default graphs that come with the debian install don't show when you > look at the 'Graph Management' section. does simply changing the order of the tables really fix the problem? my guess is that this has something to do with you running mysql-5.0, which has become some stricter syntactically speaking. i know that upstream is aware of this and will probably be releasing patches or a new version sometime in the near future to address this. in any case, if it does fix the problem i have no problem applying the patch in the meantime. > Is there a way to turn sql debugging? not within cacti that i know of, i find in my experience the poor error reporting in general is one of the application's weakpoints. sean -- signature.asc Description: Digital signature
Bug#337886: cacti: No Graphs Listed in 'Graph Management'
retitle 337886 mysql-5.0 support not quite there yet severity 337886 normal tags 337886 = upstream confirmed forwarded 337886 http://bugs.cacti.net/view.php?id=580 thanks hi jason On Tue, Nov 08, 2005 at 09:44:13AM +1100, Jason Thomas wrote: > You can close this bug. Sorry for the trouble. i think what would be better to do would be what i did above, so we can all know when the support arrives. i'll keep an eye out for a new release or entry in the "official patches" page. sean signature.asc Description: Digital signature
Bug#338202: installation error: rmdir: `/tmp/udev.LoQwmw': Directory not empty
Package: udev Version: 0.071-1 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 mini-me[~]19:36:14$ sudo apt-get install udev Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: libsepol1 The following packages will be REMOVED: hotplug The following NEW packages will be installed: libsepol1 udev 0 upgraded, 2 newly installed, 1 to remove and 53 not upgraded. Need to get 398kB of archives. After unpacking 889kB of additional disk space will be used. Do you want to continue [Y/n]? y Get:1 http://ftp.se.debian.org testing/main libsepol1 1.8-1 [81.1kB] Get:2 http://ftp.se.debian.org testing/main udev 0.071-1 [317kB] Fetched 398kB in 1s (228kB/s) (Reading database ... 178557 files and directories currently installed.) Removing hotplug ... Selecting previously deselected package libsepol1. (Reading database ... 178536 files and directories currently installed.) Unpacking libsepol1 (from .../libsepol1_1.8-1_i386.deb) ... Selecting previously deselected package udev. Unpacking udev (from .../archives/udev_0.071-1_i386.deb) ... ** * Please purge the hotplug package! ** Setting up libsepol1 (1.8-1) ... Setting up udev (0.071-1) ... Waiting for /dev to be fully populated... Populating the new /dev filesystem temporarily mounted on /tmp/udev.LoQwmw/... rmdir: `/tmp/udev.LoQwmw': Directory not empty dpkg: error processing udev (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: udev E: Sub-process /usr/bin/dpkg returned an error code (1) reperforming "apt-get install udev" afterwards seems to clear up the problem, whatever it was... though i have to admit i'm hesitant to reboot :) sean (who's going to go reboot anyway) - -- Package-specific info: - -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 0 lrwxrwxrwx 1 root root 20 2005-11-08 19:37 020_permissions.rules -> ../permissions.rules lrwxrwxrwx 1 root root 19 2005-10-29 13:54 025_libgphoto2.rules -> ../libgphoto2.rules lrwxrwxrwx 1 root root 16 2005-10-18 09:27 025_libsane.rules -> ../libsane.rules lrwxrwxrwx 1 root root 19 2005-11-08 19:37 cd-aliases.rules -> ../cd-aliases.rules lrwxrwxrwx 1 root root 13 2005-11-08 19:37 udev.rules -> ../udev.rules lrwxrwxrwx 1 root root 19 2005-11-08 19:37 z20_persistent.rules -> ../persistent.rules lrwxrwxrwx 1 root root 12 2005-11-08 19:37 z50_run.rules -> ../run.rules lrwxrwxrwx 1 root root 16 2005-11-08 19:37 z55_hotplug.rules -> ../hotplug.rules lrwxrwxrwx 1 root root 19 2005-08-24 14:55 z60_alsa-utils.rules -> ../alsa-utils.rules lrwxrwxrwx 1 root root 17 2005-11-08 19:37 z70_hotplugd.rules -> ../hotplugd.rules - -- /sys/: /sys/block/hda/dev /sys/block/hda/hda1/dev /sys/block/hda/hda2/dev /sys/block/hda/hda3/dev /sys/block/hda/hda5/dev /sys/block/hda/hda6/dev /sys/block/hda/hda7/dev /sys/block/hda/hda8/dev /sys/block/hda/hda9/dev /sys/block/hdc/dev /sys/block/ram0/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram1/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/class/input/event0/dev /sys/class/input/event1/dev /sys/class/input/event2/dev /sys/class/input/mice/dev /sys/class/input/mouse0/dev /sys/class/input/ts0/dev /sys/class/misc/agpgart/dev /sys/class/misc/hpet/dev /sys/class/misc/psaux/dev /sys/class/misc/rtc/dev /sys/class/printer/lp0/dev /sys/class/sound/adsp/dev /sys/class/sound/audio/dev /sys/class/sound/controlC0/dev /sys/class/sound/dmmidi/dev /sys/class/sound/dsp/dev /sys/class/sound/midiC0D0/dev /sys/class/sound/midi/dev /sys/class/sound/mixer/dev /sys/class/sound/pcmC0D0c/dev /sys/class/sound/pcmC0D0p/dev /sys/class/sound/pcmC0D1p/dev /sys/class/sound/pcmC0D2p/dev /sys/class/sound/timer/dev /sys/class/usb_device/usbdev1.1/dev - -- Kernel configuration: - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages udev depends on: ii initscripts 2.86.ds1-4 Standard scripts needed for bootin ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libselinux1 1.26-1 SELinux shared libraries ii libsepol1 1.8-1 Security Enhanced Linux policy lib ii lsb-base 3.0-9 Linux Standard Base 3.0 init scrip ii makedev 2.3.1-78 creates device files in /dev ii sed 4.1.4-4
Bug#338214: aterm: manpage gives incorrect locations in FILES
Package: aterm Version: 0.4.2-11 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 from man aterm: === FILES /etc/utmp System file for login records. /usr/lib/X11/rgb.txt Color names. === neither file exists at that location. should be /var/run/utmp and /etc/X11/rgb.txt (or /usr/X11R6/lib/X11/rgb.txt maybe), respectively sean - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages aterm depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libice6 6.8.2.dfsg.1-7 Inter-Client Exchange library ii libsm66.8.2.dfsg.1-7 X Window System Session Management ii libx11-6 6.8.2.dfsg.1-7 X Window System protocol client li ii libxpm4 6.8.2.dfsg.1-7 X pixmap library ii xlibs 6.8.2.dfsg.1-7 X Window System client libraries m aterm recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDcQ4FynjLPm522B0RAh62AJ9SxG2K/XW0ECd4u7ORTeaQLK2a6ACfRyWP wfNAwFGU2NABHlci62Hkn10= =15tz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338202: installation error: rmdir: `/tmp/udev.LoQwmw': Directory not empty
On Tue, Nov 08, 2005 at 07:57:34PM +0100, Marco d'Itri wrote: > It's not obvious what is happening since you did not report the content > of the directory. yes, i probably should have supplied that info... unfortunately, i've rebooted since then. fortunately, nothing evil seemd to happen on reboot besides some cryptic message about the udev "populating dev" script timing out. > I think it was a race between udevd and the init script due to a too > short timeout, if so it was fixed in a later release. > (Let me know if you have a better theory...) nope. i'll go ahead and upgrade to 0.074-1 then. sean -- signature.asc Description: Digital signature
Bug#338342: dbconfig-common: Choices should be translatable in debconf templates
hi christian, On Wed, Nov 09, 2005 at 05:49:51PM +0100, Christian Perrier wrote: > All choices should be made translatable in Choices fileds for > select/multi-select templates. This has *no* influence on your processing > scripts as values are always stored with the original English in the debconf > database. > > I suggest applying the attached patch (which I can apply myself in the CVS > but I prefer sending a prior notice). this sounds good. i won't be doing any work on the templates any time soon, so feel free to commit the changes. sean signature.asc Description: Digital signature
Bug#338391: [Pkg-nagios-devel] Bug#338391: nagios-common: nagios often leaves multiple processes around
tags 338391 = confirmed unreproducible thanks hi steve, On Wed, Nov 09, 2005 at 07:17:58PM -0600, Steve Greenland wrote: > What happens: I often (every few days? weeks?) find multiple nagios > processes running -- not children, but independent master daemons. > While this occurs, I get multiple notifications for events (or at least > some -- I told you this would be useless). Running '/etc/init.d/nagios > stop' will kill one, while the other must be killed by hand, presumably > because the pidfile is wrong/missing. i've noticed this problem as well in some cases, though i haven't been able to root out the cause or reliably reproduce it myself. i think this is the first time i've ever had to tag something both "confirmed" and "unreproducible" at the same time. my hunch is that the problem is most likely being caused by some fork/exec failure in the nagios daemon not being properly handled while executing some plugin. though this is only a hunch. i'd be curious to see if we could find some more info on the problem. for example: when there are duplicate processes, is the older or the newer in the pid file? which one(s) has an open filehandle on the nagios.cmd socket? the next time this happens for either of us, let's record that information. sena -- signature.asc Description: Digital signature
Bug#338638: [Help] How to fix a buggy prerm script in sarge? (was: Bug#338638: tetex-base: dies when /usr/local/ read-only)
hi frank, On Sun, Nov 13, 2005 at 12:25:01PM +0100, Frank Küster wrote: > we just received a bug report that is caused by a buggy prerm script > in the package in sarge (it fails because it doesn't handle read-only > /usr/local properly). Is there any way to fix this, except documenting > it in the release notes? assuming that this is only a problem with removals (and not upgrades too, in which case the problem is quite a bit more complicated), i think the best way to fix such a package would be to work with the release managers to make sure that a fixed version makes it into a sarge point-release via proposed-updates. > And on a related thought, if the bug was in the postrm script, would it > be acceptable that the preinst script of the new version edits > /var/lib/dpkg/info/tetex-base.postrm? i think you will probably get a resounding "no" from the release teams in question, from my experience with a similar problem wrt the woody->sarge path for mysql. sean -- signature.asc Description: Digital signature
Bug#329228: tetex-extra: would you consider including the "clrscode" algorithm typesetting package?
hi hilmar, On Sat, Nov 12, 2005 at 07:13:08PM +0100, Hilmar Preusse wrote: > Sorry for late response! no worries. this isn't exactly an earth shattering priority :) > For third party software we have a policy. If anybody is willing to > maintain the package as a separate one, please open an RfP or ITP bug > against wnpp. it seems kind of silly to have a single .sty (and accompanying .pdf documentation, maybe) file as an entirely seperate package. > 1. Make sure the license of the package is OK for Debian. I did not >download the package and checked it. Please do so! i did so before filing the bug report: % The author grants permission for anyone to use this macro package and % to distribute it unchanged without further restriction. If you choose % to modify this package, you must indicate that you have modified it % prior to your distributing it. I don't want to get bug reports about % changes that *you* have made! use/redistribution/modification are all covered. > 2. If you want to have it in teTeX upload it to CTAN. Normally we >forward these inclusing wishes to upstream (TE) and he normally >refuses to include package not in the contrib tree of CTAN. okay. maybe somebody with more motivation will do so :) sean -- signature.asc Description: Digital signature
Bug#332722: [Pkg-nagios-devel] Bug#332722: you are not right
On Mon, Nov 14, 2005 at 01:30:35PM +0300, Olleg Samoylov wrote: > Of cause, anyone need send perfdata to another program, to get rrd graphs. > There are two way to make this. Use service_perfdata_command. Or write > perfdata to named pipe and make parser read from it. > The second prefered, IMHO, because launch program, especially perl or awk > script > give heavy load. > There is not official perf parser. Some parsers need to be launched other > can read from named pipe. while i think your suggestion is more efficient (and lower-load in some situations), i think the default-perfdata approach is the most generally compatible. if you have a parser that can read from a named pipe, you could always make your service-perfdata command "cat >> pipe" which would minimize the load (not as good as it could be, but really not that bad either). i guess you might need a little more than that to make sure there aren't any race conditions, but we're still talking about a relatively small overhead for most installations. however, if we were to go the other way with file-perfdata, there would be no way to execute the external programs, so i chose with features and compatibility over pure efficiency. > Nagios 2.x support write to file and command. May be better instead of > deside what's better, file or command, make package for nagious 2.x? :) this is of course a good point... sean -- signature.asc Description: Digital signature
Bug#345895: mysql-server-5.0: fails to start after upgrade from 4.1; README.Debian not helpful...
hi david, caleb, first to david, thanks for the thorough report :) On Wed, Jan 04, 2006 at 03:33:38PM -0500, Caleb Epstein wrote: > This is a duplicate of #345895 but I can provide some more detail and > hopefully a fix. After updating to mysql-server-5.0, my mysqld would > not start due to the same error noted in #345895: > > Jan 4 14:14:15 tela mysqld[14638]: 060104 14:14:15 [ERROR] Fatal error: > Can't open and lock privilege tables: Can't find file: 'host' (errno: 2) > > My server has been upgraded from 3.x to 4.x nad now 5.x. At least the > "host" table in the "mysql" database was in ISAM format, which was > supported by 4.1 but is not supported by 5.0 so the server failed to > start. aha, good catch! > I was able to re-install an older mysql-server-4.1 package, run > "mysql_convert_table_format mysql" with the old server running, and > then re-install the 5.0 server. > > So I think the 5.0 server (or perhaps the 4.1 placeholder package) > should ensure that all tables are in a compatible format before > upgrading, perhaps running "mysql_convert_table_format" before > removing the old 4.1 server. okay... there's a window where we could do this in the preinst of the new packages. christian: my intuition is that this should be done in the preinst of the "real" package and not the transitional one... what do you think? also, is there an easy way to tell whether or not we need to perform the operation in the first place, or should we always perform it? sean -- signature.asc Description: Digital signature
Bug#344519: Reload cacti graph page generates mysql zombie process for every graph
severity 344519 normal tags 344519 - moreinfo thanks hi eppie, On Tue, Jan 03, 2006 at 09:37:44PM +0100, Eppie 1305 wrote: > I've done some more testing and it seems that it wasn't Cacti. > > adding a variable thread_cache_size > 0 in my.cnf did the trick for me. > > This bug can be closed. thanks for following up on this. i'll put something in README.Debian for others to find, and close the bug when i do so. in the meantime i'll re-adjust the severity. sean signature.asc Description: Digital signature
Bug#345895: mysql-server-5.0: fails to start after upgrade from 4.1; README.Debian not helpful...
hi david, caleb, On Thu, Jan 05, 2006 at 12:39:47AM -0500, Caleb Epstein wrote: > The manual fix is to run "mysql_convert_table_format mysql" to > upgrade your "mysql" database to the MyISAM table format and > then the upgrade to 5.0 should go smoothly. > > If you have any data at risk, run "mysqldump --opt > --all-databases" so you can recover your data if something > tragic happens. > > Maintainers: perhaps the preinst should check for any > databases having .IS[MD] files and abort if they are found, > warning the user to run mysql_convert_table_format or possibly > running it for them before stopping and purging the old 4.1 > server? having spent a bit of time thinking about it, it's a touch more complicated than it may seem at first glance. here are some potential gotchas: - the best/only reliable place to run this is in new.preinst. - as a result, we can only use files/scripts that exist in the older version. - this also means we can not say "we will now fail and you should read the contents of /usr/share/doc/foo" (though we could refer them to rtfm since the tfm already exists) - mysql_convert_table requires passing sensitive data on the cmdline given all this i think the following should cover it: [new.preinst] - determine list of dbs/tables containing old format, ignore if empty - debconf prompt to determine whether to abort/fix/ignore - if fix - start mysql (should be stopped by old.prerm) - issue ALTER TABLE commands manually using debian-sys-maint account - if debian-sys-maint can not connect, inform the admin and then fall back as if "abort" had been chosen. - stop mysql server so then the only thing that's missing is the actual code, and some debconf templates. christian: what do you think? could one of you guys provide me with the output from find /var/lib/mysql, to make my testing just a bit faster? thanks sean -- signature.asc Description: Digital signature
Bug#344519: Reload cacti graph page generates mysql zombie process for every graph
tags 344519 unreproducible moreinfo thanks hi epco, i'll need some more information if you would like to have help with resolving this. here are a few questions off the top of my head: - what version of mysql? - remote mysql server or local? - what's in my.cnf? - how many devices (and what kind) are you monitoring? - have you tried the suggestions from the forum report mentioned? - is this problem present with both cactid and cmd.php? - what else is using the database? - does the problem immediately happen after reboot, or only after running for some period of time? i'm tagging this as moreinfo and unreproducible... if i can't find a way to reproduce it within some period of time, i'm going to downgrade the severity too. sean -- signature.asc Description: Digital signature
Bug#335871: [Pkg-nagios-devel] Bug#335871: nagios-plugins: check_mrtg return unknown when state is ok
hi uno, On Thu, Oct 27, 2005 at 01:32:31AM +0900, UNO Takeshi wrote: > I have tried the version 1.4.2-3. > It seems to correct when the state is critical or warning, > but it still have a same bug when the state is ok. > > in check_mrtg.c(main function), there is no code to return STATE_OK, > so main() function has return STATE_UNKNOWN even no problem. lol. i tested for the unknown/warning/critical, but guess i forgot to test for the ok. so then what you suggested originally is still the case, and i'll soon upload a new version that makes sure ok works too. sean -- signature.asc Description: Digital signature
Bug#335302: More information about versions and outputs
hi thomas, On Sun, Oct 23, 2005 at 08:20:06PM +0200, Thomas Renard wrote: > Hm, wrong mysql-common? no, that's intentional. i believe now we have one mysql-common package across all versions of mysql in unstable. > + echo 'PURGE MASTER LOGS TO '\''mysql-bin.07 3377'\'';' > ERROR at line 1: Target log not found in binlog index hmm... that looks kind of strange... i believe it "should" be 'PURGE MASTER LOGS TO '\''mysql-bin.07'\'';' and somehow that extra field snuck into the variable. istr seeing this same problem a months or two back and thought it was already fixed... in 4.1.14-1 to be exact: mysql-dfsg-4.1 (4.1.14-1) unstable; urgency=high - Applied fix for changed output format of SHOW MASTER LOGS for binary log rotation (thanks to Martin Krueger). Closes: #326427, #326427 perhaps you still have the old version of the cron script? unfortunately i don't have access to the svn repository right now, but i'll send you a copy of the the "default" version to see if there are any differences as soon as i do, probably this evening. in the meantime, there has just been another update to mysql-dfsg-4.1 that includes another binary log-related problem. while i don't think it's the same issue, maybe upgrading will let you know if the file has changed (giving you the standard "this file has changed" warning), or maybe the problem will otherwise go away :) sean -- signature.asc Description: Digital signature
Bug#335737: cacti: No graphs on initial graphs screen
tags 335737 upstream forwarded 335737 http://bugs.cacti.net/view.php?id=597 thanks hi eric, On Thu, Oct 27, 2005 at 08:39:24AM -0400, Eric Blau wrote: > I also noticed that my graphs disappeared after a recent upgrade > of the following packages in testing: > > librrd0 1.0.49-1 to librrd2 1.2.11-0.4 > librrds-perl 1.0.49-1 to 1.2.11-0.4 > rrdtool 1.0.49-1 to 1.2.11.0.4 > > Reverting the packages to their previous versions and purging and recreating > the RRD files fixes the problem. okay, looks like you've nailed the problem. i see other people are having similar problems int he cacti forums/bts. i've reported a bug upstream, and will retitle the bug appropriately in the meantime. thanks! (cc'ing this to jerrywho) btw, for posterity jerrywho replied to me privately reporting similar logged errors as to was was posted here. sean -- signature.asc Description: Digital signature
Bug#335737: cacti: No graphs on initial graphs screen
On Thu, Oct 27, 2005 at 10:48:49AM -0400, Eric Blau wrote: > Thanks for looking into this problem. I had a, doh!, moment with > Cacti. I after the rrdtool upgrade, going into Settings->General and > setting the RRDtool version to 1.2.x the problem was fixed. oh, yeah, *that* option... jerrywho... can you verify that setting this option fixes your problem too? if so i'll close the bug upstream and add something into the changelog/README/NEWS. sean -- signature.asc Description: Digital signature
Bug#336186: [Pkg-nagios-devel] Bug#336186: nagios-common: Apache, Apache2, Apache-SSL, Both?
On Fri, Oct 28, 2005 at 02:28:40PM +0200, Olaf van der Spek wrote: > > Automatically configure apache for Nagios? > > > Apache, Apache2, Apache-SSL, Both, None > > What does both do? the whole chunk of webserver related code needs to be rewritten... it's on my todo list :) > > Suggested packages: kernel-image-2.6 > > Shouldn't that be linux-image-2.6 now? yup. sean signature.asc Description: Digital signature
Bug#336228: libmysqlclient14-dev: trying to overwrite `/usr/include/mysql/my_dbug.h', which is also in package libmysqlclient15-dev
hi robert, On Fri, Oct 28, 2005 at 08:45:29PM +0200, Robert Trebula wrote: > Unpacking libmysqlclient14-dev (from > .../libmysqlclient14-dev_4.1.15-1_i386.deb) ... > dpkg: error processing > /var/cache/apt/archives/libmysqlclient14-dev_4.1.15-1_i386.deb (--unpack): > trying to overwrite `/usr/include/mysql/my_dbug.h', which is also in package > libmysqlclient15-dev > dpkg-deb: subprocess paste killed by signal (Broken pipe) > Errors were encountered while processing: > /var/cache/apt/archives/libmysqlclient14-dev_4.1.15-1_i386.deb as far as i know, these two packages should have been conflicting, as they provide many (almost entirely) overlapping files. christian: any reason we shouldn't add a conflicts entry? sean -- signature.asc Description: Digital signature
Bug#336531: cacti: Cacti is incompatible with mysql server 5.x
tags 336531 = confirmed severity 336531 important forwarded 336531 http://bugs.cacti.net/view.php?id=580 thanks hi miah, On Mon, Oct 31, 2005 at 12:21:10AM +, Miah Gregory wrote: > Following the mysql 5 upgrade, cacti's front end ceases to work > correctly. This is due to changes in how mysql 5 processes certain types > of query. thanks for bringing this to my attention. i think i saw evidence that upstream is arranging a fix for it as i saw some diffs from svn a week ago or so where many of the queries were re-written with ()'s. anyway, i've subscribed to the bug in question, so when they release a patch or a new version of cacti to fix the bug, i'll upload it. in the meantime, i'll consider uploading a version that explicitly conflicts with mysql 5.0 after i investigate how well the "workaround" suggested by TheWitness works. sean -- signature.asc Description: Digital signature
Bug#336639: [Pkg-nagios-devel] Bug#336639: nagios-plugins: ftbfs [sparc] check_game.c:75: error: 'PATH_TO_QSTAT' undeclared
hi blars, On Mon, Oct 31, 2005 at 08:39:15AM -0800, Blars Blarson wrote: > nagios-plugins failed to build on a sparc buildd, but did build on my > sparc pbuilder. i'm fairly certain i know what the problem is here, i was having it previously and thought that i had resolved it but apparently not. i'll try and push out an upload in a bit. sean signature.asc Description: Digital signature
Bug#337082: mysql-dfsg-5.0_5.0.15-1(m68k/unstable/zeus): FTBFS on m68k
hi christian, On Wed, Nov 02, 2005 at 05:13:17PM +0100, Christian Hammers wrote: > On 2005-11-02 Stephen R Marenka wrote: > > mysql-dfsg-5.0 fails to build from source on m68k. It looks like we're > > into the headers protected by #ifdef __KERNEL__, so I'm not sure where > > you want to go. > Thanks for the log. > > I think I saw this problem some weeks ago and it had been fixed upstream or > by a patch from us. > > Sean, do you have time to take a look at it? I'm not at home until > Saturday. i'll try taking a look through the changelog/bts this afternoon to at least see how the last problem was solved, and work from there. sean -- signature.asc Description: Digital signature
Bug#337112: cacti-cactid: cactid doesn't use /etc/cacti/cactid.conf
hi,
On Wed, Nov 02, 2005 at 06:39:59PM +0100, Michael Bussmann wrote:
> A dry-run on the command line showed that cactid could not open
> the connection to the DBMS (too bad this error message is printed
> on stdout instead of stderr, so the logfiles don't show anything
> interesting (cronjob: >/dev/null 2>/var/log/cacti/poller-error.log)
ew. if you could find the relevant error message, i'll patch it to
spit it out to stderr instead (where it should go in the first place)
> Strace'ing the process showed that cactid tries to open the wrong
> config file:
>
> | 19526 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
> | 19526 open("cactid.conf", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> | 19526 open("/etc/cacticactid.conf", O_RDONLY) = -1 ENOENT (No such file or
> directory)
^
hmm... looks like the search path was changed to remove the trailing '/'
from the directory where the config file is. it shouldn't be too hard
to fix that up.
> A dirty workaround is to place a symlink of /etc/cacti/cactid.conf in
> /usr/sbin.
good to know there's something that will work in the meantime :)
sean
--
signature.asc
Description: Digital signature
Bug#337112: cacti-cactid: cactid doesn't use /etc/cacti/cactid.conf
hi michael, On Thu, Nov 03, 2005 at 08:42:50AM +0100, Michael Bussmann wrote: > Thanks for your fast response. attribute it to the timezone difference :) anyway, i'll be sending an upload in a few minutes, which should both fix the bug in question and also send error messages to stderr. if you could verify both work for you, i'd appreciate it. i've put up the debs etc on my p.d.o site in the meantime, so you don't have to wait for the autobuilders/mirror-pulses: http://people.debian.org/~seanius/cacti-cactid/sid sean signature.asc Description: Digital signature
Bug#337112: cacti-cactid: cactid doesn't use /etc/cacti/cactid.conf
On Thu, Nov 03, 2005 at 11:09:00AM +0100, Michael Bussmann wrote: > On 2005-11-03 04:24:34 -0500, sean finney wrote: > > Had a sleepless night, eh? :-) heh, actually, i'm writing my emails on a server in pennsylvania, but i'm actually writing them from sweden, where i've been GMT+1 the whole time :) > However, the error messages are still being printed on stdout > > | [EMAIL PROTECTED] [1005] =>cactid 1 1 >/dev/null > | [EMAIL PROTECTED] [1006] => > > I think this is due to the fact that the messages do not contain > "ERROR" or "WARNING" (utils.c:582, after patch 02) > > But the main bug is fixed so I can finally remove that ugly symlink. okay, so we got the important thing, anyway. if upstream accepts my patch i'll mention these further issues. sean -- signature.asc Description: Digital signature
Bug#339324: python-metakit: support for python2.4?
Package: python-metakit Version: 2.4.9.3-5 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, is there any reason there is not a python2.4-metakit package? thanks, sean - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages python-metakit depends on: ii python2.3-metakit 2.4.9.3-5 Metakit bindings for python2.3 python-metakit recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDee9vynjLPm522B0RAgVMAJ94cbw2cWmCbpa1FGzTvv0m30GlnQCeNPfq sqrcL4zFq0qpMTJu/uukRP8= =9akU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339327: linux-2.6: don't display lilo-related messages unless lilo is installed
Package: linux-2.6 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, i sometimes get messages like the following: The link /vmlinuz.old is a damaged link Removing symbolic link vmlinuz.old Unless you used the optional flag in lilo, you may need to re-run lilo The link /initrd.img.old is a damaged link Removing symbolic link initrd.img.old Unless you used the optional flag in lilo, you may need to re-run lilo a simple "which lilo" could probably determine whether mentioning lilo were appropriate. sean - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDefRlynjLPm522B0RAt2vAJ9cdSjNHB+Tp/bKg5kisGF4neMeBACfYo3Y FnpeLzJ8gHKVQ5sk5tzy874= =2zcD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339366: [Pkg-nagios-devel] Bug#339366: After update, Nagios runs, but no status
hi daniel, On Tue, Nov 15, 2005 at 09:03:02PM +, Daniel Pocock wrote: > I reviewed the NEWS file and manually corrected the paths in > /etc/nagios/nagios.cfg: > > command_file=/var/run/nagios/nagios.cmd > status_file=/var/cache/nagios/status.log > temp_file=/var/cache/nagios/nagios.tmp > state_retention_file=/var/cache/nagios/status.sav > log_file=/var/log/nagios/nagios.log > comment_file=/var/log/nagios/comment.log > downtime_file=/var/log/nagios/downtime.log > lock_file=/var/log/nagios/nagios.lock > log_archive_path=/var/log/nagios/archives you might want to check cgi.cfg to make sure the settings in that are also good. for example, nagios_check_command, maybe. > agios problem: located 3 processes, status log updated 1132088447 > seconds ago my guess that 1132088447 seconds ago was the epoch when you did the check, and that this resulted from something funny with the status log. > However, that time interval seems very wrong after I check the file time > by hand: > > /etc/nagios# date > Tue Nov 15 21:01:44 GMT 2005 > /etc/nagios# ls -l /var/cache/nagios/status.log > -rw-rw-r-- 1 nagios nagios 0 Nov 15 21:01 /var/cache/nagios/status.log > > I can see that Nagios is performing the checks, but I can't see the > status. Does anybody know what is wrong? check_nagios actually checks data inside the file for a timestamp, so the fact that it has a size of zero makes me suspect this may be the root of the problem. might want to make sure the nagios daemon is actually writing into there and not somewhere else. also, might want to make sure that /etc/init.d/nagios stop actually stops nagios, as there seem to be spurious problems of runaway nagios processes when restarting the daemon. sean -- signature.asc Description: Digital signature
Bug#339401: [Pkg-nagios-devel] Bug#339401: Inconsistent paths in init script
hi daniel, On Wed, Nov 16, 2005 at 12:53:22AM +, Daniel Pocock wrote: > CHECK_NAGIOS=`grep '^nagios_check_command=' /etc/nagios/cgi.cfg | cut -b22-` the init script situation has been a thorn in our side for a bit. i just sat down and improved things a bit. we already have a "get_config" function, which i've simply augmented to also be able to check cgi.cfg as well, so the issues with the named pipe and status log locations should go away in the next upload. thanks, sean -- signature.asc Description: Digital signature
Bug#339971: [Pkg-nagios-devel] Bug#339971: nagios-plugins-basic: upgrade trouble from sarge?
hi lars, On Sun, Nov 20, 2005 at 01:42:46AM +0200, Lars Wirzenius wrote: > While testing upgrades of nsca from sarge via etch to sid, with > piuparts, I ran into the following problem with nagios-plugins-basic, > which gets dragged in by apt-get: nsca used to depend on nagios-plugins, which is a rather dependency heavy package. to close a number of bugs (and to make nagios-related packages a little more useful) i split off the nagios-plugins packages into two packages, one of which only having minimal dependencies. each plugin (check_foo) has a conffile like you see below: > Configuration file `/etc/nagios-plugins/config/disk.cfg' >==> File on system created by you or by a script. >==> File also in package provided by package maintainer. > What would you like to do about it ? Your options are: > Y or I : install the package maintainer's version > N or O : keep your currently-installed version > D : show the differences between the versions > Z : background this process to examine the situation >The default action is to keep your current version. so when some plugins moved from one package to the other, so did their conffiles. so, this would be appropriate, then, correct? > The entire piuparts log file is over 200 kilobytes, so I won't attach > it, but I will gladly mail it on request, if you think it would be > helpful. if you feel there is a genuine problem, then i'd be happy to see it, though i'd need some concrete recommendations on what you think should be done to resolve the problem. thanks sean signature.asc Description: Digital signature
Bug#339985: [Pkg-nagios-devel] Bug#339985: nagios-pgsql: bug in supplied check_nagios_db
hi dave, On Sun, Nov 20, 2005 at 03:09:14AM +, Dave Page wrote: > The check_nagios_db script supplied in /usr/share/doc/nagios-common/ > gets its nagios configuration information from /etc/nagios/cgi.cfg > However, when called at boot time, it needs the parameters from > /etc/nagios/resource.cfg to make sure i understand the situation correctly: if nagios-pgsql is set up so that different users are used to connect via the nagios daemon and the web interface, there's a problem with check_nagios_db when called from the init script vs. when called from the web interface? could you clarify this, and provide a concrete example of what you'd like to see? i have some upcoming changes to the check_nagios_db and init script infrastructure, so hearing from you about what you'd like to hear relatively soon might mean getting it in rather promptly. sean -- signature.asc Description: Digital signature
Bug#339366: [Pkg-nagios-devel] Bug#339366: After update, Nagios runs, but no status
tags 339366 upstream thanks hi daniel, On Wed, Nov 16, 2005 at 12:44:07AM +, Daniel Pocock wrote: > I've now discovered the cause of this problem. > > The /var partition was full. It had been eaten up mostly by the > contents of /var/cache/apt/ (I did apt-get dist-upgrade yesterday). > > Therefore, I would suggest that Nagios should log an error if it can't > write status.log due to disk space constraints or any other IO failure. that seems fairly reasonable. i don't have the time to look into the matter myself, but would be more than willing to accept a patch. i will also forward the matter upstream to the nagios development mailing list. sean -- signature.asc Description: Digital signature
Bug#324216: [EMAIL PROTECTED]: Status of bug #324216]
defaults ++ tail -n 1 + pidfile=/var/run/mysqld/mysqld.pid + '[' -f /var/run/mysqld/mysqld.pid ']' + '[' check_alive = check_alive -a 0 = 1 ']' + '[' check_alive = check_dead -a 0 = 0 -a 0 = 0 ']' + '[' nowarn = warn ']' + return 1 + for i in 1 2 3 4 5 6 + sleep 1 + mysqld_status check_alive nowarn ++ /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping + ping_output='/usr/bin/mysqladmin: connect to server at '\''localhost'\'' failed error: '\''Can'\''t connect to local MySQL server through socket '\''/var/run/mysqld/mysqld.sock'\'' (111)'\'' Check that mysqld is running and that the socket: '\''/var/run/mysqld/mysqld.sock'\'' exists!' + ping_alive=0 + ps_alive=0 ++ mysqld_get_param pid-file ++ /usr/sbin/mysqld --print-defaults ++ tr ' ' '\n' ++ grep -- --pid-file ++ tail -n 1 ++ cut -d= -f2 + pidfile=/var/run/mysqld/mysqld.pid + '[' -f /var/run/mysqld/mysqld.pid ']' + '[' check_alive = check_alive -a 0 = 1 ']' + '[' check_alive = check_dead -a 0 = 0 -a 0 = 0 ']' + '[' nowarn = warn ']' + return 1 + for i in 1 2 3 4 5 6 + sleep 1 + mysqld_status check_alive nowarn ++ /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping + ping_output='/usr/bin/mysqladmin: connect to server at '\''localhost'\'' failed error: '\''Can'\''t connect to local MySQL server through socket '\''/var/run/mysqld/mysqld.sock'\'' (111)'\'' Check that mysqld is running and that the socket: '\''/var/run/mysqld/mysqld.sock'\'' exists!' + ping_alive=0 + ps_alive=0 ++ mysqld_get_param pid-file ++ /usr/sbin/mysqld --print-defaults ++ tr ' ' '\n' ++ grep -- --pid-file ++ tail -n 1 ++ cut -d= -f2 + pidfile=/var/run/mysqld/mysqld.pid + '[' -f /var/run/mysqld/mysqld.pid ']' + '[' check_alive = check_alive -a 0 = 1 ']' + '[' check_alive = check_dead -a 0 = 0 -a 0 = 0 ']' + '[' nowarn = warn ']' + return 1 + for i in 1 2 3 4 5 6 + sleep 1 + mysqld_status check_alive nowarn ++ /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping + ping_output='/usr/bin/mysqladmin: connect to server at '\''localhost'\'' failed error: '\''Can'\''t connect to local MySQL server through socket '\''/var/run/mysqld/mysqld.sock'\'' (111)'\'' Check that mysqld is running and that the socket: '\''/var/run/mysqld/mysqld.sock'\'' exists!' + ping_alive=0 + ps_alive=0 ++ mysqld_get_param pid-file ++ /usr/sbin/mysqld --print-defaults ++ tr ' ' '\n' ++ grep -- --pid-file ++ tail -n 1 ++ cut -d= -f2 + pidfile=/var/run/mysqld/mysqld.pid + '[' -f /var/run/mysqld/mysqld.pid ']' + '[' check_alive = check_alive -a 0 = 1 ']' + '[' check_alive = check_dead -a 0 = 0 -a 0 = 0 ']' + '[' nowarn = warn ']' + return 1 + mysqld_status check_alive warn ++ /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping + ping_output='/usr/bin/mysqladmin: connect to server at '\''localhost'\'' failed error: '\''Can'\''t connect to local MySQL server through socket '\''/var/run/mysqld/mysqld.sock'\'' (111)'\'' Check that mysqld is running and that the socket: '\''/var/run/mysqld/mysqld.sock'\'' exists!' + ping_alive=0 + ps_alive=0 ++ mysqld_get_param pid-file ++ /usr/sbin/mysqld --print-defaults ++ grep -- --pid-file ++ tail -n 1 ++ cut -d= -f2 ++ tr ' ' '\n' + pidfile=/var/run/mysqld/mysqld.pid + '[' -f /var/run/mysqld/mysqld.pid ']' + '[' check_alive = check_alive -a 0 = 1 ']' + '[' check_alive = check_dead -a 0 = 0 -a 0 = 0 ']' + '[' warn = warn ']' + /bin/echo -e '0 processes alive and '\''/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping'\'' resulted in\n/usr/bin/mysqladmin: connect to server at '\''localhost'\'' failed error: '\''Can'\''t connect to local MySQL server through socket '\''/var/run/mysqld/mysqld.sock'\'' (111)'\'' Check that mysqld is running and that the socket: '\''/var/run/mysqld/mysqld.sock'\'' exists!\n
Bug#324216: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Status of bug #324216]]
clone 324216 -1
retitle -1 problems with mysqld + innodb + tls
tags -1 = moreinfo
thanks
it seems that some wires got crossed somewhere, as #324216 was
originally about binlog file permissions causing a different kind
of crash, and this seems to be a seperate issue altogether.
so, i'm splitting off the bug into a new report. i'll contact
the second reporter when i get a new bug id and ask for a bit more
info before i forward the bug upstream.
sean
- Forwarded message from sean finney <[EMAIL PROTECTED]> -
Date: Mon, 21 Nov 2005 04:46:22 -0500
From: sean finney <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [EMAIL PROTECTED]: Status of bug #324216]
below is some information forwarded w/permission from tero ripattila.
executive summary is that the problem seems to have something to
do with innodb and tls not getting along together.
a temporary workaround is provided below, but not verified by myself.
sean
- Forwarded message from Tero Ripattila <[EMAIL PROTECTED]> -
Date: Sat, 19 Nov 2005 15:05:41 +0200
From: Tero Ripattila <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Status of bug #324216
Hello Sean, I'd like to kindly ask what's status of the bug
#324216,<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324216>?
I having same difficulties here as described in the bug log and I
cannot solve this issue on my own.
Actually I got the sig 11 too. Here comes output of my ldd:
$ ldd /usr/sbin/mysqld
librt.so.1 => /lib/tls/librt.so.1 (0x4001d000)
libz.so.1 => /usr/lib/libz.so.1 (0x40023000)
libwrap.so.0 => /lib/libwrap.so.0 (0x40035000)
libdl.so.2 => /lib/tls/libdl.so.2 (0x4003e000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40042000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0x40051000)
libnsl.so.1 => /lib/tls/libnsl.so.1 (0x4007e000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40092000)
libm.so.6 => /lib/tls/libm.so.6 (0x4014c000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4016e000)
libc.so.6 => /lib/tls/libc.so.6 (0x40177000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
I'm quite new to Debian as I've been using only OpenBSD for past four
years.
Looking forward to hearing from you soon.
Regards, Tero
--
Tero Ripattila
- End forwarded message -
- Forwarded message from Tero Ripattila <[EMAIL PROTECTED]> -
Date: Sat, 19 Nov 2005 17:25:52 +0200
From: Tero Ripattila <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Strace indicates that InnoDB support is broken (Was: Re: Status
of bug #324216)
Hello guys, sorry for spamming you, but I'd like to let you know that
this crash may have been caused by InnoDB routines. Please see the
following strace:
execve("/usr/sbin/mysqld", ["/usr/sbin/mysqld", "--basedir=/usr",
"--datadir=/var/lib/mysql", "--user=mysql",
"--pid-file=/var/run/mysqld/mysqld.pid", "--skip-locking",
"--port=3306", "--socket=/var/run/mysqld/mysqld.sock"], [/* 18 vars
*/]) = 0
set_thread_area({entry_number:-1 -> 0, base_addr:0x402acd20,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 123
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
051119 17:04:09 InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this
binary
or one of the libraries it was linked against is corrupt, improperly
built,
or misconfigured. This error can also be caused by malfunctioning
hardware.
We will try our best to scrape up some info that will hopefully help
diagnose
the problem, but since we have already crashed, something is definitely
wrong
and this may fail.
key_buffer_size=0
read_buffer_size=131072
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections
= 217599 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=(nil)
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x425d27d8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81893bf
0x4004caf8
(nil)
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html
and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please
do
resolve it
Th
Bug#286501: [Pkg-nagios-devel] Bug#286501: Nagios 2.0 packaging status
hey maurice, On Tue, Jun 07, 2005 at 05:35:01PM +0200, Maurice Massar wrote: > as the Sarge-release made it out well yesterday, > what are the plans about packaging Nagios 2.0? (: i've been getting numerous requests about this. i would assume that unless 2.0 comes out before then, something will be appearing in experimental within the next month, while i sort out upgrade-path related issues. sean -- signature.asc Description: Digital signature
Bug#312562: mysql-server: Bogus stack limit or frame pointer, fp=0x4261f7d8, stack_bottom=0x4b0,
hi daniele, On Wed, Jun 08, 2005 at 09:34:28PM +0200, Daniele Muscetta wrote: > After upgrading from stable to stable (sarge 3.1 is just stable, I did a > dist-upgrade of the machine), everything > works fine, EXCEPT mysql which does not start trowing this error: > > > Jun 7 23:17:26 muscetta mysqld[13935]: mysqld got signal 11; that's a segfault. no fun. could you run: strace -f strace.out /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid and send us a copy of strace.out? sean -- signature.asc Description: Digital signature
Bug#312562: mysql-server: Bogus stack limit or frame pointer, fp=0x4261f7d8, stack_bottom=0x4b0,
On Wed, Jun 08, 2005 at 11:30:22PM +0200, Daniele Muscetta wrote: > >could you run: > > > >strace -f strace.out /usr/sbin/mysqld --basedir=/usr > >--datadir=/var/lib/mysql --user=mysql > >--pid-file=/var/run/mysqld/mysqld.pid > >and send us a copy of strace.out? > > > sure, here you go (attached). is this an strace from the daemon while it was having the problem you reported, or after you attempted the various other things you did? it doesn't look like it's segfaulting anymore from this trace, but instead having some other problem. > One thing is that the machine is now probably messed up I tryed to > upgrade mysql-server to mysql-server-4.1, then it was doing the same > error, so I removed the whole lot (removed mysql-common and > dependencies), and re-tried with 4.0 again also trid at one point to > rename my /var/lib/mysql to let it create a new one (so there should be > no old db to convert/upgrade, right ?) it was still giving the same. > I might run a second strace in that scenario, if you think it's worth > seeing any difference. something i'd recommend: after making a full backup of whatever db stuff you still have, try *purging* mysql-*, rm -rf /var/lib/mysql, and reinstall it and see if a default empty install has this problem. note that you can't really downgrade from 4.1 back to 4.0 without some problems so let's keep it on 4.0 while we try to figure this out. > [Please note that I've contacted also the hosting provider, as they > provide the kernel (it is a UML machine) - in fact, it might be hardware > (virtualization) related also bind9 was failing with a segfault > after the upgrade, and I have had to resort back (at least in the > meanwhile) to bind8 which instead starts fine everything else works > as expected, these mails are passing through this very same box, for > instance :-)] these could be related. i don't have access to a UML environment, so i can't say that i tested the latest version of mysql in there. i wouldn't rule that out, anyway. by the way, are you doing anything out of the ordinary with nsswitch? ldap? nis? sean signature.asc Description: Digital signature
Bug#312657: cacti-cactid: Undistributable binary, links with OpenSSL
tags 312657 confirmed upstream forwarded 312657 http://bugs.cacti.net/view.php?id=485 thanks reported to the upstream author's bts. thanks. sean On Thu, Jun 09, 2005 at 02:55:08PM +0300, Faidon Liambotis wrote: > Package: cacti-cactid > Severity: normal > > cacti-cactid links with OpenSSL (and depends on libssl0.9.7), but it is > licensed under GPL (without OpenSSL exception). This makes the resulting > binary undistributable due to (GPL) license violation. > > More about GPL/OpenSSL conflict: > http://www.gnome.org/~markmc/openssl-and-the-gpl.html > > Regards, > Faidon > > -- System Information: > Debian Release: 3.1 > APT prefers unstable > APT policy: (50, 'unstable') > Architecture: i386 (i686) > Kernel: Linux 2.6.9 > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) > > Versions of packages cacti-cactid depends on: > ii cacti 0.8.6c-7 Frontend to rrdtool for > monitoring > ii debconf 1.4.30.13Debian configuration management > sy > ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries > an > ii libmysqlclient124.0.24-10mysql database client library > ii libsnmp55.1.2-6.1NET SNMP (Simple Network > Managemen > ii libssl0.9.7 0.9.7e-3 SSL shared libraries > ii zlib1g 1:1.2.2-4compression library - runtime > -- signature.asc Description: Digital signature
Bug#312562: mysql-server: Bogus stack limit or frame pointer, fp=0x4261f7d8, stack_bottom=0x4b0,
tags 312562 unreproducible retitle 312562 mysqld segfaults with 2.6 kernels in UML. thanks hi, On Thu, Jun 09, 2005 at 08:16:31AM +0200, Daniele Muscetta wrote: > it has the problems in converting innodb tables having messed up myself > with 4.0 -> 4.1 and back to 4.0 ;) > ...but after that (I forgot to temporarly disable innodb with > "skip-innodb" just to go further... and then it would have crashed the > same way. my bad, it was quite late last night when i did that :-)) okay, well i won't be able to look any further into this until i can at least see the strace, or ideally have access to a simlar system. > hosting provider swapped the kernel "under the hood" with a 2.4.x (but > still with UML obviously) and it now works. > Also bind9 which was segfaulting now runs fine hmm... well i'll retitle the bug appropriately for the meantime, maybe it's some wierd threading issue... > I might let you talk with the hosting provider, as they run a lot of > those 2.6 UML machines and in fact they thought right away it was > related I CC them in this mail, eventually you can follow up with > them if you think it is necessary to have this properly tested in case > it happens to other people too i'd like to test this further, but to do so i'd need access to a similar environment. can i either get such access or detailed instructions on how to set it up? the former would be ideal, as the latter would take more of my time and therefore make it less likely that i could actually sit down and poke at the problem. sean -- signature.asc Description: Digital signature
Bug#312689: mysql-server: mysql -utest does no work any longer
hi uwe, On Thu, Jun 09, 2005 at 05:21:21PM +, Uwe Brauer wrote: > mysql -utest > > worked always, in suse and after switching to debian (4.0.22). > > Now when I upgraded to 4.0.24 the command did not work > I got > > ERROR 1045: Access denied for user: '[EMAIL PROTECTED]' (Using password: NO this is because we've removed anonymous access to the database for default installations. please trust us that this is a good thing :) if you want to test connectivity to your mysql database, you will need to set up yourself an account/password, or recreate the default access. > Another point: I saw that version 4.0.24 in all, three branches > (stable testing unstable) and I fail to see the rationale behind > this. If for some reason a version in unstable has a bug I could > downgrade to the older version, but now I can't. The only explanation > for this policy seems to me a serious security problem. before sarge came out, there were three versions available stable: 3.23 testing: 4.0.x/4.1.x unstable: 4.0.x/4.1.x now, there are only two versions available (4.0.x/4.1.x) in all three releases. at some point, this will change when we introduce 5.0 into unstable, when we will probably at least remove 4.0.x from the unstable and testing releases. so about this bug, i'm not sure what more you want from it. if there are no objections, i'll go ahead and close it... sean -- signature.asc Description: Digital signature
Bug#312806: cacti: Manual scripts fails
hi gaetan, On Fri, Jun 10, 2005 at 09:58:27AM +0200, Gaetan RYCKEBOER wrote: > For now, it appears that only SNMP datas are available. > I presume it would be a path problem, since the multiple cacti logs in > full verbose mode, complains regularly on paths. could you send me a copy of the logs you're getting? note that because the paths have changed, you will have to update cacti to know about the new locations. for example if you're using script server templates, you may have to edit the files and reload them inside of cacti from their new paths. sean -- signature.asc Description: Digital signature
Bug#312562: NPTL support broken in Linux 2.6 UML
tags 312562 confirmed sid tags 312562 - unreproducible retitle 312562 UML causes mysqld to segfault (NPTL issue) reassign 312562 user-mode-linux thanks hi roberto, On Fri, Jun 10, 2005 at 05:29:55PM +0200, Roberto Suarez Soto wrote: > I've just stumbled onto this bug searching for other ones, and I think > I know the cause: NPTL. NPTL is broken in UML for Linux 2.6, and this breaks > many programs. > > The workaround is to move /lib/tls out of the way (/lib/tls.DISABLED, > for example). Doing this and rebooting the UML (to ensure that no program > remains with the "bad" libraries in memory) should fix it. thanks for pointing this out! i was really scratching my head on this one. i was suspicious that it might have been threading related, but didn't have a way to verify it without sitting down and hacking with UML myself. so, i'll reassign this bug to user-mode-linux. i notice that this was kept out of sarge, so thankfully this means that this is not a problem that should be hitting most people. thanks again, sean -- signature.asc Description: Digital signature
Bug#313006: Bug#313005: INTL:vi
tags 313005 pending tags 313006 pending thanks translations committed to svn, will be included in the next upload. thanks! sean -- signature.asc Description: Digital signature
Bug#310842: cacti: Fix for poller silently failing
tags 310842 = confirmed sarge fixed patch thanks hey mark, On Tue, Jun 14, 2005 at 12:00:15PM +0100, Mark Sheppard wrote: > Package: cacti > Version: 0.8.6d-1 > Tags: patch > Followup-For: Bug #310842 > > I've finally got round to looking at this properly. Turns out that awesome! thanks for figuring this out, i was really lost on this one. i will include this patch in the next upload, though i will leave this bug open and appropriately tagged for anyone who's using sarge and runs across this. sean -- signature.asc Description: Digital signature
Bug#313190: INTL:vi
tags 313190 pending thanks hi, On Sun, Jun 12, 2005 at 09:02:12PM +0930, Clytie Siddall wrote: > Package: cacti > Version: 0.8.6d-1 > Severity: minor > Tags: l10n, patch > > The Vietnamese translation for debconf: cacti will be uploaded shortly, thanks! sean -- signature.asc Description: Digital signature
Bug#314620: [l10n] Czech translation for cacti
tags 314620 moreinfo thanks hi martin, On Fri, Jun 17, 2005 at 03:43:15PM +0200, Martin ?ín wrote: > Package: cacti > Severity: wishlist > Tags: l10n, patch > > In attachement there is initial Czech translation (cs.po) for cacti > package, please include it. how is this different from the po file you gave me in #311095? thanks, sean -- signature.asc Description: Digital signature
Bug#313191: cacti
tags 313191 pending thanks hi, On Sun, Jun 12, 2005 at 09:02:27PM +0930, Clytie Siddall wrote: > While translating the file cacti, I encountered the following typos, > which I thought you might like to eliminate in a future release. yeah, actually those templates are obsoleted and unused. so i've gone ahead and removed them from the package. thanks for pointing them out! sean -- signature.asc Description: Digital signature
Bug#313192: INTL:vi
tags 313192 pending thanks hi, On Sun, Jun 12, 2005 at 09:08:14PM +0930, Clytie Siddall wrote: > Package: cacti-cactid > Version: 0.8.6d-7 > Severity: minor > Tags: l10n, patch > > The Vietnamese translation for debconf: cacti-cactid committed in svn, will be in the next upload. thanks! sean -- signature.asc Description: Digital signature
Bug#310526: mysql-dfsg-4.1: [INTL:fr] French debconf templates translation
tags 310526 pending thanks committed in CVS, thanks. sean ps - apologies for the lack of notice with the template change, we were in a rather tight bind time-wise to get a fix in for sarge. -- signature.asc Description: Digital signature
Bug#310510: mysql-server: Invalid reference in "BerkelyDB is obsolete" warning
hi philipp, On Tue, May 24, 2005 at 03:06:43AM +0200, Philipp Weis wrote: > | /etc/init.d/mysql[21166]: BerkeleyDB is obsolete, see > /usr/share/doc/mysql-server/README.Debian.gz > > I have a README.Debian in the referenced directory, but it does not > mention BerkeleyDB at all. are you using BDB databases, or only have BDB enabled? the warning is valid (BDB support is either disabled or on its way to being disabled, i'm not sure), but it looks like the documentation on this is lacking. sean -- signature.asc Description: Digital signature
Bug#310197: mysql-dfsg-4.1: [INTL:ru] Russian debconf templates translation
tags 310197 pending tags 310263 pending thanks hi, On Sun, May 22, 2005 at 10:07:22PM +1000, Yuriy Talakan' wrote: > Please use this updated Russian debconf templates translation On Mon, May 23, 2005 at 03:43:38AM +0900, Hideki Yamane wrote: > I forgot to translate two lines, so send updated one again. both of these are now fixed in cvs. > ...and I found typo. i'll fix this shortly too, but want to take the time to not fuzzy up everyone's translations. thanks, sean -- signature.asc Description: Digital signature
Bug#310579: mysql-server-4.1: Full log partitions result in an indefinite wait loop
forwarded 310579 http://bugs.mysql.com/bug.php?id=10866 thanks hi erik, i've forwarded this one upstream... sean -- signature.asc Description: Digital signature
Bug#310878: MySQL: Auto-increment not working with INSERT..SELECT and NDB storage
tags 310878 sarge sid forwarded 310878 http://bugs.mysql.com/bug.php?id=9675 thanks hi halef, On Thu, May 26, 2005 at 07:22:11PM +0200, halef omar wrote: > This Bug unfortunately causes some trouble using MySQL > in an > clustering environment: > see: http://bugs.mysql.com/bug.php?id=9675 thanks for reporting this. unfortunately, the fix will not make it into sarge, but at least we have this as a point of reference for anyone else who gets bitten by this. when the fix comes out for sid, i'll update the bug report and rmeove the sid tag. sean -- signature.asc Description: Digital signature
Bug#310605: mysqld: chroot happens too early
severity 310605 wishlist tags 310605 upstream tags 310605 confirmed forwarded 310605 http://bugs.mysql.com/bug.php?id=9244 thanks hi stephen, On Tue, May 24, 2005 at 08:56:45AM -0700, Stephen Gildea wrote: > Package: mysql-server > Version: 4.0.24-5 > > I have some suggestions to make it easier to use mysqld's "chroot" i believe this has already been reported (or something similar to it, anyway) in #299265. it's been forwarded upstream to the mysql folks, and there's a bug that exists in their BTS for it. i've subscribed to the bug so when it's updated i'll know and i can update our local BTS accordingly. thanks, sean -- signature.asc Description: Digital signature
Bug#310987: please test new version of cacti in unstable
merge 308492 310842 310987 thanks hi, i believe all of the above mentioned bugs are caused by the same poller-related problem. while i have not yet been able to reproduce the problem i'm pretty sure that it is there because of the number of people independantly reporting it. in the absence of more evidence, could some of you try the latest version of cacti uploaded into sid today? the version is 0.8.6d, and is a new upstream release. sean -- signature.asc Description: Digital signature
Bug#310967: [Pkg-nagios-devel] Bug#310967: nagios-text: Default url to cgi-bin is not valid with default configuration of apache and apache2
tags 310967 unreproducible tags 310967 moreinfo thanks hi stanislav, On Fri, May 27, 2005 at 04:38:32PM +0600, Stanislav V. Vlasov wrote: > After installing nagios-text and apache (was tryed apache and apache2 > packages) urls, similar to http://host/nagios/cgi-bin/bin.cgi return > not result of cgi, but it content. > Both apache and apache2 was installed in default configuration without > any changes in config by hand. i'm not able to duplicate this problem. this is what i did: 1 - debootstrapped a sarge base system (with /proc mounted) 2 - chrooted into this directory 2 - apt-get install nagios-text and everything works just fine for me. the reason why it would spit out the content of the cgi's would be that you didn't have LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so somewhere in your apache configuration, though this *should* be enabled by default. could you take another look at this? thanks, sean -- signature.asc Description: Digital signature
Bug#310987: please test new version of cacti in unstable
hi, On Tue, May 31, 2005 at 02:34:16PM +0100, Mark Sheppard wrote: > I just gave that new version a go, but it's still broken. I'm still > getting the "PHPSVR: Poller[0] ERROR: Input Expected, Script Server > Terminating" message in the logs. damn. back to the drawing board i guess. i'll try and come up with some more ideas. in the meantime, if you would feel comfortable doing so, having a mysqldump of your cacti install (with passwords, ip addresses, and snmpd community names masked out, and sent outside of the BTS) would be very helpful. otherwise, i could probably throw a couple specific mysql queries your way to get what i think i need to know, though it'll take me a bit of time to put that together. sean -- signature.asc Description: Digital signature
Bug#311526: [Pkg-nagios-devel] Bug#311526: nagios-common: purging package removed configuration files from another package
tags 311526 confirmed sarge sid
thanks
On Wed, Jun 01, 2005 at 05:06:24PM +0200, Norbert Tretkowski wrote:
> Package: nagios-common
> Severity: grave
> Justification: renders package unusable
>
> From nagios-common's postrm:
>
> | rm -Rf {/var/cache,/var/run,/var/log,/etc}/nagios
>
> Removing /etc/nagios is a _bad_ idea, especially when you still have
> other nagios related packages like nagios-nrpe-server installed.
yeah, this is definitely a bad idea. i think this particular line
predates our management of the package, which is probably how it
slipped under our radar.
i'm cc'ing debian-release on this one... coming up with a fix for this
shouldn't be too complicated or take too long and i can probably get it
done very late this evening (EDT). is this too late for sarge? if so,
i'll put the update in for the first sarge update.
sean
--
signature.asc
Description: Digital signature
Bug#311550: If sugarplum modifies apache2 config it does not activate mod_rewrite
hi there, On Wed, Jun 01, 2005 at 09:41:35PM +0200, Markus Blatt wrote: > This it did but unfortunately the needed mod_rewrite was not activated > automatically. It would really be need if sugarplum coult check whether > mod_rewrite is activated and if not activate it autmatically. this seems pretty reasonable. the apache folks provide a script to enable modules, so all that should need to be done is call the appropriate invocation of apache-modconf for each server for which we're configuring sugarplum. i'll put this in my TODO list... sean -- signature.asc Description: Digital signature
Bug#311526: [Pkg-nagios-devel] Bug#311526: nagios-common: purging package removed configuration files from another package
hey, On Wed, Jun 01, 2005 at 09:56:42PM -0700, Steve Langasek wrote: > I would very much like to see this fixed for sarge, but it seems to now be > quie late in the evening EDT. Is this something that still has a chance of > being uploaded before tomorrow's dinstall? crap... i didn't end up getting back in time to do this last night. i'll get it done asap and then we can decide whether or not that is fast enough for sarge. sean -- signature.asc Description: Digital signature
Bug#311526: [Pkg-nagios-devel] Bug#311526: nagios-common: purging package removed configuration files from another package
On Wed, Jun 01, 2005 at 09:56:42PM -0700, Steve Langasek wrote: > I would very much like to see this fixed for sarge, but it seems to now be > quie late in the evening EDT. Is this something that still has a chance of > being uploaded before tomorrow's dinstall? okay, i have something ready to go, and i'll upload it as soon as i finish testing it. i'm going to upload it straight to sid with urgency=high... if i should be using t-p-u instead, let me know. sean -- signature.asc Description: Digital signature
Bug#311526: [Pkg-nagios-devel] Bug#311526: nagios-common: purging package removed configuration files from another package
tags 311526 +pending -sid thanks hey, i've uploaded a new version to sid that should fix this problem. i'll keep the bug open until the fix makes it's way into sarge... sean -- signature.asc Description: Digital signature
Bug#311695: [Pkg-nagios-devel] Bug#311695: nagios-mysql: default config fills disk
tags 311695 unreproducible thanks hi andres, On Thu, Jun 02, 2005 at 03:13:31PM -0400, Andres Salomon wrote: > [1117732808] Error: Could not insert retention data for host 'gw' in > table 'hostretention' > [1117732808] Error: Could not insert retention data for host 'gw' in > table 'hostretention' > [1117732808] Error: Could not insert retention data for host 'gw' in > table 'hostretention' > [1117732808] Error: Could not insert retention data for host 'gw' in > table 'hostretention' did you flush privileges after granting them? these error messages are usually from 'access denied' type messages. looking over the README.mysql, it doesn't look like this is mentioned, but it is definitely a necessary step. also, make sure that it's not some hung nagios process. if you have multiple nagios processes, there's a chance that a previously hung one from before when the access was granted is the culprit. you should be able to just kill them. sean -- signature.asc Description: Digital signature
Bug#311695: bug #311695: i'm not getting updates, wierd
strange, i'm not sure why, but i've missed out on everything past the first post. my guess is that there's something wrong with the alioth mailing lists (where the bug reports should be sent) or something, but, eh anyway, i'm a bit hesitant to be patching nagios this close to sarge, no matter how simple the patch seems. so unless i hear any convincing objections, i'll include it in the next non-sarge upload. sean -- signature.asc Description: Digital signature
Bug#311836: mysql-server init.d script: want useful status exit status
hi stephen, On Fri, Jun 03, 2005 at 09:47:26AM -0700, Stephen Gildea wrote: > Package: mysql-server > Version: 4.0.24-10 > Tags: patch > > The init script for mysql-server implements a "status" command, which is > useful for humans. But that command doesn't use different exit values > for different statuses, making it useless for scripts. thanks for this. we will include it once some time is freed up and the earth stops shaking from sarge's pending release :) sean -- signature.asc Description: Digital signature
Bug#311695: [Pkg-nagios-devel] Bug#311695: hey, let's loop endlessly doing sql statements!
On Fri, Jun 03, 2005 at 12:25:38PM -0400, Andres Salomon wrote: > severity 311695 critical > thanks > > Bumping severity back to RC, as I can now reproduce this easily, it > breaks the system, it causes data loss, it raped my cat, it really is > evil behavior, and we already know how to fix it. okay, well i see a few options: - try and patch nagios source for nagios-mysql at the last minute. - take our time, keep the rc bug and put the fix in 3.1r1 - have nagios not start by default (at least for nagios-mysql, if that's possible) i don't like the first one, and the third one also requires a non-trivial amount of code change and affects the other two versions of nagios which might not have this problem. so given this, plus the fact that there's an easy workaround (follow directions and configure your server), i don't think that the world would end if this fix didn't make it in in time for sarge. so that's my 2 cents anyway... sean -- signature.asc Description: Digital signature
Bug#276057: progress on this ITP?
hi evan, how is the progress coming along with this ITP? i'm interested in using this software, but would rather not have to go out of my way to manage it outside of a package management system :) if part of the problem is that you don't have the time to get the database-related stuff setup (or even if you've already done so), might i suggest that you take a look at the dbconfig-common project[1]? currently dbconfig-common only exists in experimental, but it's at a point where if someone wanted to use it in unstable i wouldn't mind uploading it there. sean [1] http://people.debian.org/~seanius/policy/dbconfig-common.html -- signature.asc Description: Digital signature
Bug#292473: [Pkg-nagios-devel] Bug#292473: acknowledged by developer (Bug#292473: fixed in nagios 2:1.3-cvs.20050402-1)
hi cyril, On Fri, Apr 15, 2005 at 10:45:51AM +0300, Cyril Bouthors wrote: > > - is there anything else from your syslog from around these times? > > Nothing. and what about in the nagios logs? > > - are there any cronjobs that coincide with this? > > The crontab is ~100 lines long but nothing is related to Nagios > (except the stupid script that restart it in this case). are there any cronjobs (even unrelated) that run around this time though? my thought that something like a log rotation or a mysql dump might be stealing all of some kind of resource, causing the forks in nagios to fail. > > - what else is running on this server? > > Apache, MySQL, CVS, NFS, arpwatch, snmpd, log2mail, DHCP, SSH, RSYNC, > Munin, MRTG, Exim4, ircd-hybrid, hddtemp, Bind. > > None of those interferes with Nagios. hmm.. could you post (or send privately if you prefer) your nagios.cfg? looking at that may give me an idea of some settings changes that might help as well. sean -- signature.asc Description: Digital signature
Bug#291775: any progress on this?
hi filip, On Fri, Apr 15, 2005 at 04:27:10PM +0200, Filip Sneppe wrote: > Sorry, I hadn't given this any of my attention lately... > > How does the attached patch look ? that's looks pretty good. i'll see about getting this in before the next upload. one thing i did notice though is that the author did not explicitly say what the license terms are of grouplist.cgi. i don't think i'd be making a gross assumption to assume that this can be distributed under the same terms as nagios (since the nagios is GPL'd and the GPL says it has to be), but it would be nice to have it from the author himself. but anyway, i won't let that get in the way of including it in the package in the meantime. thanks! sean -- signature.asc Description: Digital signature
