Bug#1026062: Upstream bugs
Upstream has merged this fix patch: https://github.com/PackageKit/PackageKit-Qt/commit/e6cb7890c4193b65a55cf295eb963ac4463c81c1
Bug#1026062:
Dear Maintainer, Looks like I am affected too. Checking for updates in Discover reproduces the bug too. Logs before crash: > Jan 03 15:24:23 debian kded5[20091]: apper.daemon: Creating Helper > Jan 03 15:24:23 debian kded5[20091]: apper.daemon: System is not ready, > application should conserve resources > Jan 03 15:24:23 debian kded5[20091]: Registering > "org.kde.StatusNotifierHost-8129" > as system tray > Jan 03 15:24:23 debian kded5[20091]: packagekitqt.transaction: Unknown > Transaction > property: "Sender" QVariant(QString, ":1.261") > Jan 03 15:24:24 debian ksmserver[2051]: packagekitqt.transaction: Unknown > Transaction property: "Sender" QVariant(QString, ":1.69") > Jan 03 15:24:24 debian kded5[20091]: KCrash: Attempting to start > /usr/bin/kded5 > Jan 03 15:24:24 debian kded5[20091]: 19 -- exe=/usr/bin/kded5 > Jan 03 15:24:24 debian kded5[20091]: 13 -- platform=xcb > Jan 03 15:24:24 debian kded5[20091]: 11 -- display=:0 > Jan 03 15:24:24 debian kded5[20091]: 14 -- appname=kded5 > Jan 03 15:24:24 debian kded5[20091]: 17 -- apppath=/usr/bin > Jan 03 15:24:24 debian kded5[20091]: 10 -- signal=11 > Jan 03 15:24:24 debian kded5[20091]: 10 -- pid=20091 > Jan 03 15:24:24 debian kded5[20091]: 12 -- startupid=0 > Jan 03 15:24:24 debian kded5[20091]: 15 -- restarted=true > Jan 03 15:24:24 debian kded5[20091]: KCrash: crashing... > crashRecursionCounter = 2 > Jan 03 15:24:24 debian kded5[20091]: KCrash: Application Name = kded5 path = > /usr/bin > pid = 20091 > Jan 03 15:24:24 debian kded5[20091]: KCrash: Arguments: /usr/bin/kded5 coredumpctl info: >PID: 20091 (kded5) >UID: 1000 (enthlinn) >GID: 1000 (enthlinn) > Signal: 11 (SEGV) > Timestamp: Tue 2023-01-03 15:24:24 CST (12min ago) > Command Line: /usr/bin/kded5 > Executable: /usr/bin/kded5 > Control Group: > /user.slice/user-1000.slice/user@1000.service/session.slice/plasma-kded.service > Unit: user@1000.service > User Unit: plasma-kded.service > Slice: user-1000.slice > Owner UID: 1000 (enthlinn) >Boot ID: 77e22213bf294a60b90de56312eff42f > Machine ID: c2d6c4e3f4cc448796b02e37ce7e86f3 > Hostname: debian >Storage: > /var/lib/systemd/coredump/core.kded5.1000.77e22213bf294a60b90de56312eff42f.20091 > .167273066400.zst (present) > Size on Disk: 4.9M >Message: Process 20091 (kded5) of user 1000 dumped core. > > Module libudev.so.1 from deb systemd-252.4-1.amd64 > Module libsystemd.so.0 from deb systemd-252.4-1.amd64 > Stack trace of thread 20091: > #0 0x7fb84a5e0ccc n/a (libc.so.6 + 0x8accc) > #1 0x7fb84a591ef2 raise (libc.so.6 + 0x3bef2) > #2 0x7fb84afdb86d _ZN6KCrash19defaultCrashHandlerEi > (libKF5Crash.so.5 + 0x586d) > #3 0x7fb84a591f90 n/a (libc.so.6 + 0x3bf90) > #4 0x7fb7f0078ba4 _ZNK10PackageKit11Transaction4roleEv > (libpackagekitqt5.so.1 + 0x1aba4) > #5 0x7fb7f010faae n/a (kded_apperd.so + 0xeaae) > #6 0x7fb7f010fb99 n/a (kded_apperd.so + 0xeb99) > #7 0x7fb84a2e8fcf n/a (libQt5Core.so.5 + 0x2e8fcf) > #8 0x7fb7f006c095 > _ZN10PackageKit6Daemon22transactionListChangedERK11QStringList > (libpackagekitqt5.so.1 + 0xe095) > #9 0x7fb84a2e8ffc n/a (libQt5Core.so.5 + 0x2e8ffc) > #10 0x7fb7f0084b38 n/a (libpackagekitqt5.so.1 + 0x26b38) > #11 0x7fb7f0085d73 n/a (libpackagekitqt5.so.1 + 0x27d73) > #12 0x7fb84aefc61b n/a (libQt5DBus.so.5 + 0x2361b) > #13 0x7fb84a2dd770 _ZN7QObject5eventEP6QEvent > (libQt5Core.so.5 + 0x2dd770) > #14 0x7fb84b162f5e > _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 > + > 0x162f5e) > #15 0x7fb84a2b17c8 > _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + > 0x2b17c8) > #16 0x7fb84a2b4761 > _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData > (libQt5Core.so.5 + 0x2b4761) > #17 0x7fb84a30a1d3 n/a (libQt5Core.so.5 + 0x30a1d3) > #18 0x7fb8490657a9 g_main_context_dispatch > (libglib-2.0.so.0 + 0x547a9) > #19 0x7fb849065a38 n/a (libglib-2.0.so.0 + 0x54a38) > #20 0x7fb849065acc g_main_context_iteration > (libglib-2.0.so.0 + 0x54acc) > #21 0x7fb84a3098b6 > _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFla > gEE (libQt5Core.so.5 + 0x3098b6) > #22 0x7fb84a2b024b > _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + > 0x2b024b) > #23 0x7fb84a2b83b6 _ZN16QCoreApplication4execEv > (libQt5Core.so.5 + 0x2b83b6)
Bug#906111: openjdk-8-jre: Package should Provide: java-runtime
Package: openjdk-8-jre Version: 8u181-b13-1 Severity: normal Dear Maintainer, Package openjdk-8-jre has Provides: java2-runtime, java5-runtime, java6-runtime, java7-runtime, java8-runtime It is missing "java-runtime". As result, some other packages that depend on java-runtime will force installation of JRE 7 (too old) or JRE 10 (too new, some tools still do not support it) and having JRE 8 will not satisfy their dependencies. Other JRE versions in debian have "java-runtime" in their Provides:. Package openjdk-7-jre Provides: java-runtime, java2-runtime, java5-runtime, java6-runtime, java7-runtime Package openjdk-10-jre Provides: java-runtime, java10-runtime, java2-runtime, java5-runtime, java6-runtime, java7-runtime, java8-runtime, java9-runtime Please add java-runtime to "Provides" section in the control file. Equivalent ..-jdk packages do not suffer from this problem (JDK 7,8 and 10 provide "java-jdk") -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openjdk-8-jre depends on: ii libasound2 1.1.6-1 ii libatk-wrapper-java-jni 0.33.3-21 ii libc62.27-5 ii libgif7 5.1.4-3 ii libgl1 1.0.0+git20180308-4 ii libgl1-mesa-glx 18.1.5-1 ii libglib2.0-0 2.56.1-2 ii libgtk-3-0 3.22.30-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libpng16-16 1.6.34-2 ii libpulse012.0-1 ii libx11-6 2:1.6.5-1 ii libxext6 2:1.3.3-1+b2 ii libxinerama1 2:1.1.3-1+b3 ii libxrandr2 2:1.5.1-1 ii openjdk-8-jre-headless 8u181-b13-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openjdk-8-jre recommends: pn fonts-dejavu-extra Versions of packages openjdk-8-jre suggests: pn icedtea-8-plugin -- no debconf information
Bug#597713: clvm: ocf resource for pacemaker is not included but needed
Package: clvm Version: 2.02.66-3 Severity: normal Just setting up a cluster on a different box and, in configuring pacemaker found that I could not use ocf:lvm2:clvmd as the required file (/usr/lib/ocf/resource.d/lvm2/clvmd) is missing. It would be a good idea to include this in squeeze especially since a -lot- of documentation on the net refers to it. Without it people may feel a fair bit lost and I'm currently having problems using /etc/init.d/clvm. The URL of Ultimate Usefulness for this would be: https://build.opensuse.org/package/files?package=lvm2-clvmproject=Base%3ASystem Thanks. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.35.4 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504500: FSL 4.1.1 problem
When trying to load an fsf file (design file) in the feat gui (one that
ran successfully under 4.0) I got the following error output:
can't read fmri(confoun: no such variable
can't read fmri(confoun: no such variable
while executing
set fmri(confoun
(file
/raid/research/autism_mri/2nd_level_analyses/eo-ao_face_design.fsf
line 329)
invoked from within
source ${filename}
(procedure feat5:load line 25)
invoked from within
feat5:load .r 1
/raid/research/autism_mri/2nd_level_analyses/eo-ao_face_design.fsf
(eval body line 1)
invoked from within
eval $command $outputfile1
(procedure feat_file:invoke line 29)
invoked from within
feat_file:invoke .wdialog1 a a a :: {feat5:load .r 1}
invoked from within
.wdialog1.f4.but_ok invoke
(uplevel body line 1)
invoked from within
uplevel #0 [list $w invoke]
(procedure tk::ButtonUp line 22)
invoked from within
tk::ButtonUp .wdialog1.f4.but_ok
(command bound to event)
--
*Dr. Catherine Hanson*
Rutgers University
email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Smith Hall, Psychology
phone: (973) 353-5440, ext 3947
101 Warren St.
fax: 866-434-7959
Newark, NJ 07102
Bug#286273: 3 inches, but a world of difference
Show your hot date a sizzling time in the sack. http://www.albagrowths.com/ Slap that cute tight ass -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#197771: A little tab'll do ya.
All the soma you will ever need, here - http://Diplodoubles.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338830: barstow autism
Get Prescrpitions tomorrow www.austriaabater.apr.claimhuge.com and addedaward barstow may baroque -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#232487: It keeps going and going and going
Hello If you experience some lapses in your sexual life, please, do not hesitate or make your life worse. Just a blue-pill will cure all your doubts and restore the life you will not help enjoying. http://besthotelsoxford.com Regards The ePharmacy Team. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443264: [Pkg-shadow-devel] Bug#443264: Bug#443264: closed by Nicolas Fran??ois [EMAIL PROTECTED] (Re: Bug#443264: passwd: useradd ignores default group and creates usergroups instead)
On Sun, Sep 23, 2007 at 09:33:05AM +0200, Christian Perrier wrote: I'd agree except that this isn't necessarily set in stone. It's only present in an in-flux distribution of Debian (Lenny/Sid) and Etch doesn't even have the switch at all (and is currently stuck with a default totally different to its predecessors). Even the comments in the Etch config file seems to indicate (in somewhat confused English :) Yeah. Re-reading the comments make me feel ashamed...:) Other then: bo Rewrite help welcomed, indeed... Your mail address is in Australia so I suspect you have a better English than the two Frenchies who maintain shadow currently (Christine could help as well: hey Christine?!) Hehe. Sure. I could do a bit of wordiness tidy-upping. :) I take it a patchlike thing to the file would be it? The behaviour I'm thinking of would be more like: (big headache for me) well, it's quite well argumented even if I'm a bit lost..:-). So I grant Nicolas with a carte blanche to change this after discussing the implementation details with you...:) Any news? I was kinda waiting (so as not to spam the bug) for Nicolas but it may be that Nicolas is waiting for me. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443264: [Pkg-shadow-devel] Bug#443264: closed by Nicolas Fran??ois [EMAIL PROTECTED] (Re: Bug#443264: passwd: useradd ignores default group and creates usergroups instead)
On Sat, Sep 22, 2007 at 10:39:17AM +0200, Christian Perrier wrote: Would it be possible to modify this slightly to say that if a GROUP= line is given in the configuration file then -n is implied and that is used, otherwise make a new one? It seems to me to be slightly better behaviour as it, at least to me, easily follows from the actual act of setting a single, solid group. I have mitigated feelings about a setting in the configuration file to change the default setting of the program switches. As such, your proposal is an interesting compromise, yes. However, I wouldn't like to introduce confusion in the use of the software. I'd agree except that this isn't necessarily set in stone. It's only present in an in-flux distribution of Debian (Lenny/Sid) and Etch doesn't even have the switch at all (and is currently stuck with a default totally different to its predecessors). Even the comments in the Etch config file seems to indicate (in somewhat confused English :) ) something other then what has occured: # The default group for users # 1000=users on Debian systems # same then USERS_GID in adduser # Please be aware that Debian's adduser defaults to user groups # which means that one group is created for each user # There is no way to achieve this with useradd which must remains a low # level utility # GROUP=100 The behaviour I'm thinking of would be more like: No switch, no default GROUP define: Keep the etch/red hat specific way No switch, GROUP defined: use GROUP and behave as useradd always has under Debian. -n specified, no default GROUP: use group 1 as per manpage (not sure why group 1 was chosen but hey) -n specified, GROUP defined: use GROUP The behaviour of -n doesn't /really/ change and keeps useradd functioning in a mannger compatible with Red Hat. The behaviour of useradd without -n would change from present Lenny (and Etch, since it would then finally do as the docs suggest). With this, no scripts written under previous versions of Debian need change and scripts from Red Hat based systems can still be ported. People who wish 1 group/user setup of useradd can still have it and those who wish the longstanding behaviour can still have it also. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443264: closed by Nicolas Fran??ois [EMAIL PROTECTED] (Re: [Pkg-shadow-devel] Bug#443264: passwd: useradd ignores default group and creates usergroups instead)
On Thu, Sep 20, 2007 at 09:06:05AM +, Debian Bug Tracking System wrote: This was fixed in the version 1:4.0.18.1-8 of shadow (and passwd). This version is not available on Etch. In the Etch version, the default behavior, when -g is not specified, is always to use/create the primary user group with the same name as the user. The 1:4.0.18.1-8 version introduced a -n flag to disable this, and use the group specified in the configuration file. Would it be possible to modify this slightly to say that if a GROUP= line is given in the configuration file then -n is implied and that is used, otherwise make a new one? It seems to me to be slightly better behaviour as it, at least to me, easily follows from the actual act of setting a single, solid group. The recommended tool for the creation of users in a Debian system is adduser (useradd is a low level tool). I would recommend you to use this tool. The USERGROUPS and USERS_GID variables of /etc/adduser.conf will probably satisfy your needs (not tested, but it would make sense). Aye. Just that this change is chucking away around a decades+ worth of learnt behaviour. The above modification would be a good compromise as it allows one to set the command for the old behaviour or keep the new. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443390: php5-cgi: -c config file settings overriden by global config
Package: php5-cgi Version: 5.2.0-8+etch7 Severity: normal It would appear that php5-cgi reads the file specified by -c first, parses it and then follows it up with the global config files (/etc/php5/...). The end effect of this is that there is no way to override the globals for, say, some site or some other use via this option and as such makes it rather useless. I confirmed this by running php5-cgi -c ... first and verifying the config reported by phpinfo(). None of the desired changes were registered. I then did an mv /etc/php5 /etc/php5.old and ran php5-cgi -c ... again and verified. The desired changes were present then. I believe simply switching the order the config files are read/parsed in would fix this. -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22.1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443264: passwd: useradd ignores default group and creates usergroups instead
Package: passwd Version: 1:4.0.18.1-7 Severity: normal I am trying to add a new user to the system whose group will automatically be set to 'users' but useradd fails to do so: # useradd test # id test uid=1007(test) gid=1007(test) groups=1007(test) # userdel test # useradd -D GROUP=100 HOME=/home INACTIVE=-1 EXPIRE= SHELL=/bin/sh SKEL=/etc/skel CREATE_MAIL_SPOOL=no Doing useradd -D -g 1000 then useradd -D -g 100 (to make sure that it writes stuff out to the file) does not change the broken behaviour. I have seen this happen on 2 etch systems upgraded from sarge and 1 etch system that was built fresh. This also occurs wether or not GROUP=100 is explicitly in /etc/default/useradd or not. -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22.1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages passwd depends on: ii debianutils2.17 Miscellaneous utilities specific t ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii libpam-modules 0.79-4Pluggable Authentication Modules f ii libpam0g 0.79-4Pluggable Authentication Modules l ii libselinux11.32-3SELinux shared libraries ii login 1:4.0.18.1-7 system login tools passwd recommends no packages. -- debconf information: passwd/password-mismatch: passwd/username: passwd/password-empty: * passwd/md5: true passwd/user-uid: * passwd/shadow: true passwd/username-bad: passwd/user-fullname: * passwd/make-user: false passwd/title: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399930: logrotation race condition with exim writing to logs
On Fri, Nov 24, 2006 at 10:23:38AM +0100, Marc Haber wrote: On Fri, Nov 24, 2006 at 05:11:25PM +1100, CaT wrote: So there is absolutely no need for the create option in logrotate Not having the logs created might break monitoring mechanisms. Well it is kind of a choice between maybe breaking poorly written monitoring schemes (the lack of a log should merely be a hint to check deeper rather then be the be-all and end-all of ones decision making) and definately breaking the very system that they are meant to monitor. My personal vote is for keeping the system running. Breaken monitoring is a minor annoyance that causes no harm and should only happen when the monitoring is really broken anyway. A broken mail server can well lead to massive tear-shedding when it goes down suddenly and abruptly. For me this meant manual babysitting of the reinjection of mail back from the backup MXes into the virus filter (which wound up getting seriously stressed) and then into the mail storage server (which just plain broke as it needs replacement). This was further aggrivated as it took me away from the task of building the gruntier, better, faster replacement for the mail storage server. My Wednesday sucked. Our customers Wednesday suck. Our support staffs Wednesday sucked. It just plain all sucked. In comparison to that an inapporpriate page/email/sms/whatever from a monitoring system that doesn't check things well enough to indcate a server is down when it isn't is just a minor joykill at worst. Sorry if I seem a bit heavy about this but, well, it just all plain sucked. :/ -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399930: logrotation race condition with exim writing to logs
On Fri, Nov 24, 2006 at 01:15:01PM +0100, Marc Haber wrote: On Fri, Nov 24, 2006 at 10:58:28PM +1100, CaT wrote: On Fri, Nov 24, 2006 at 10:23:38AM +0100, Marc Haber wrote: On Fri, Nov 24, 2006 at 05:11:25PM +1100, CaT wrote: So there is absolutely no need for the create option in logrotate Not having the logs created might break monitoring mechanisms. Well it is kind of a choice between maybe breaking poorly written monitoring schemes (the lack of a log should merely be a hint to check deeper rather then be the be-all and end-all of ones decision making) and definately breaking the very system that they are meant to monitor. I consider this race condition to be minor, since it obviously only happens on very heavily loaded systems, which should have a competent Well not really. It's just more likely to happen on a heavily loaded system due to the increased number of msgs it processes. It can happen with any system. It only takes one message to come in at the right time. system admin around to isolate the issue. You are always free to And an on-call monkey who actually gives you a call. :/ As with all problems that cause tears they're mostlikely to occur when you're asleep. change the configuration yourself, /etc/logrotate.d/exim4-base is a dpkg-conffile. I'm already bulding my own debs for this, which is annoying as I'm not doing this to add features but to fix some brokenness. The thing is, there's no need to precreate the logfile (broken monitoring systems aside) and doing so can break things and has broken things. I'd say the opposite tact should be taken. If you are relying on a monitoring system that relies on the logfile always being there then have it pre-created and deal with the race condition of the mintor slot where there is no logfile between the move of the old and the creation of the new. The priority should be to make sure the things the exim package setup do not cause exim to die. Other things should take care of themselves. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399930: logrotation race condition with exim writing to logs
On Fri, Nov 24, 2006 at 10:23:38AM +0100, Marc Haber wrote: On Fri, Nov 24, 2006 at 05:11:25PM +1100, CaT wrote: So there is absolutely no need for the create option in logrotate Not having the logs created might break monitoring mechanisms. Sorry, the other thing about this: Testing as to wether or not the logfile exists does not test wether exim is functioning. It's the logrotation that creates the logfile and so a test for its presence is a test for logrotation and nothing more. As such you need to have your monitoring system test further in order to report the right thing. Testing for logfile deltas is not effected by having the logrotation mechanism create (or not create) the logfile as you are testing for changes from one check to the next. Not having a change in the logfile does not indicate a service is down though. It could just indicate things are quiet and so it's just a hint for other things. Testing the content of the logfile for certain clues as to status is not effected by the logfiles lack either. You still have to check to see what that means. Is the service down or did the logrotation just fail in a bizarre way. In short there's nothing really gained by precreating the logfile except a small chance for pain. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399930: logrotation race condition with exim writing to logs
Actually, the permissions on the exim created logfile will be correct seeing as #-- # The log files themselves are created as required, with a mode that # defaults # to 0640, but which can be changed here. # LOG_MODE=0640 So there is absolutely no need for the create option in logrotate (but seeing as 'create' is set by default it should be replaced with nocreate). -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399930: exim4: logrotation race condition with exim writing to logs
Package: exim4 Version: 4.50-8sarge2 Severity: normal Yesterday exim died with the following error in the panic log: 2006-11-22 06:25:23 +1100 Cannot open main log file /var/log/exim4/mainlog: Permission denied: euid=102 egid=102 This was a fairly busy server so by the time I managed to get to it 20k messages got backed up. Having thought about it though the only way I could see the above happening would be due to a race condition in logrotate between logrotates create option fulfilling its duties and exim trying to deliver/accept an email. I think it would've gone a little like this: logrotate rotates the logs logrotate creates a new log file due to the create option exim attempts to log to the new logfile exim fails to log as logfile is owned root.adm (no write permissions) exim panics and bails logrotate chowns logfile to Debian-exim.adm logrotate chmods logfile 640 It was a slim chance but I cannot think of what else might have happened. The obvious fix, as far as I can see, was to replace the create option with nocreate. It's not necessary as exim will automatically attempt to create the logfile if it's missing and since the log dir is owned by Debian-exim and exim has write permissions it'll succeed. The dir is also group sticky so the new file will automatically get group-owned to adm. About the only thing that'll be lacking, I think, is the group read permission but that's better then no mail server IMO. If I'm wrong then I'm lost as to an explanation for what happened. This was with a custom build of 4.62-1, btw though I have checked and the logrotation is thesame for the standard sarge build. -- Package-specific info: Exim version 4.50 #1 built 11-Apr-2006 12:29:22 Copyright (c) University of Cambridge 2004 Berkeley DB: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) Support for: iconv() IPv6 GnuTLS Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Configuration file is /var/lib/exim4/config.autogenerated -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.16.29 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages exim4 depends on: ii exim4-base 4.50-8sarge2 support files for all exim MTA (v4 ii exim4-daemon-light 4.50-8sarge2 lightweight exim MTA (v4) daemon -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320737: apt-file: Add find as a synonym for search
Package: apt-file
Version: 2.0.3-7
Severity: wishlist
Tags: patch
Please? For the sweet sweet love of god have mercy! :/
--- /usr/bin/apt-file.old 2005-08-01 14:27:35.0 +1000
+++ /usr/bin/apt-file 2005-08-01 14:28:45.0 +1000
@@ -281,6 +281,7 @@
Action:
update Fetch Contents files from apt-sources.
search pattern Search files in packages
+find pattern Synonym for search pattern
list pattern List files in packages
purge Remove cache files
EOF
@@ -342,11 +343,12 @@
my $actions = {
update = \fetch_files,
search = \grep_file,
+ find = \grep_file,
list = \grep_package,
purge = \purge_cache,
};
-$Conf-{help}=2 if $Conf-{action} =~ m/search|list/
+$Conf-{help}=2 if $Conf-{action} =~ m/find|search|list/
! defined $Conf-{pattern};
$Conf-{help}=2 if ! defined $actions-{$Conf-{action}}
! defined $Conf-{help};
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.11-mm3
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)
Versions of packages apt-file depends on:
ii gzip 1.3.5-10 The GNU compression utility
ii libapt-pkg-perl 0.1.13 Perl interface to libapt-pkg
ii libconfigfile-perl1.2.1 Parses simple configuration files
ii perl 5.8.4-8Larry Wall's Practical Extraction
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317598: procmail accepts messages even though partition full
On Mon, Jul 11, 2005 at 01:58:36PM +0200, Santiago Vila wrote: severity 317598 normal thanks I reiterate that I can't take this report seriously unless you tell me a way to reproduce it. In particular, you didn't tell me about your Have we spoken about this previously? I had a look at the archived bugs for procmail incase I reported this before but I can't find anything. Either via the list of archived bugs for procmail or via searching for my email address. procmail.log file at all. What do you need to know? I still have it but as it's big (190mb) I don't wish to mail it out (plus it contains private info :). I'm downgrading the severity to normal, as I don't want to see a non-reproducible bug in the periodical list of bugs that must be fixed urgently. I'll be working on a test case for you but it might take a bit. As you can see from the logs it's a bit hit and miss. Sometimes it recognises the condition correctly and sometimes it does not and the emails vanish. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317598: procmail accepts messages even though partition full
Package: procmail Version: 3.22-11 Severity: critical Justification: causes serious data loss Tonight my /var/mail partition ran out of disk space (again) and procmail continued to allow delivery (again) despite of this. It occasionally rejected messages via return code 75: Jul 10 10:35:09 theirongiant fetchmail[1063]: reading message [EMAIL PROTECTED]:4 of 4 (2982 octets) Jul 10 10:35:11 theirongiant fetchmail[1063]: MDA returned nonzero status 75 Jul 10 10:35:11 theirongiant fetchmail[1063]: not flushed And all is well, but in the same hit it also decides that accepting is a great idea: Jul 10 10:35:07 theirongiant fetchmail[1063]: 4 messages for cat at zipworld.com.au (13738 octets). Jul 10 10:35:07 theirongiant fetchmail[1063]: reading message [EMAIL PROTECTED]:1 of 4 (2949 octets) Jul 10 10:35:08 theirongiant fetchmail[1063]: flushed Jul 10 10:35:08 theirongiant fetchmail[1063]: reading message [EMAIL PROTECTED]:2 of 4 (4429 octets) Jul 10 10:35:09 theirongiant fetchmail[1063]: flushed Jul 10 10:35:09 theirongiant fetchmail[1063]: reading message [EMAIL PROTECTED]:3 of 4 (3378 octets) Jul 10 10:35:09 theirongiant fetchmail[1063]: flushed And those messages are lost. The next time around it accepted the message it rejected above and so it was lost. It doesn't do it for just one message out of the pickup: Jul 10 10:40:58 theirongiant fetchmail[1063]: 4 messages for cat at zipworld.com .au (14719 octets). Jul 10 10:40:58 theirongiant fetchmail[1063]: reading message [EMAIL PROTECTED] u:1 of 4 (2615 octets) Jul 10 10:40:58 theirongiant fetchmail[1063]: flushed Jul 10 10:40:58 theirongiant fetchmail[1063]: reading message [EMAIL PROTECTED] u:2 of 4 (8077 octets) Jul 10 10:41:00 theirongiant fetchmail[1063]: MDA returned nonzero status 75 Jul 10 10:41:00 theirongiant fetchmail[1063]: not flushed Jul 10 10:41:00 theirongiant fetchmail[1063]: reading message [EMAIL PROTECTED] u:3 of 4 (2010 octets) Jul 10 10:41:00 theirongiant fetchmail[1063]: MDA returned nonzero status 75 Jul 10 10:41:00 theirongiant fetchmail[1063]: not flushed Jul 10 10:41:00 theirongiant fetchmail[1063]: reading message [EMAIL PROTECTED] u:4 of 4 (2017 octets) Jul 10 10:41:01 theirongiant fetchmail[1063]: flushed 2 messages gone and 2 messages saved. Procmail is called via the following in fetchmail: mda /usr/sbin/sensible-mda %F %T '' localhost Which is the way sendmail calls it. Help? This is rather annoying. I just lost a whole nights worth of email. :/ -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.11-mm3 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Versions of packages procmail depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
