Bug#1072814: mutt -A '' generates a segmentation fault
Package: mutt
Version: 2.2.12-0.1~deb12u1
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I was useing -A to look up aliases.
* What exactly did you do (or not do) that was effective (or
ineffective)?
mutt -A ''
* What was the outcome of this action?
crash.
* What outcome did you expect instead?
I expended an empty result.
*** End of the template - remove these template lines ***
-- Package-specific info:
Mutt 2.2.12 (2023-09-09)
Copyright (C) 1996-2023 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
System: Linux 6.1.0-15-amd64 (x86_64)
ncurses: ncurses 6.4.20221231 (compiled with 6.4)
libidn2: 2.3.3 (compiled with 2.3.3)
hcache backend: tokyocabinet 1.4.48
Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)
Configure options: --build=x86_64-linux-gnu --prefix=/usr
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
'--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
'--libdir=${prefix}/lib/x86_64-linux-gnu' --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking
--with-mailpath=/var/mail --enable-compressed --enable-debug --enable-fcntl
--enable-hcache --enable-gpgme --enable-imap --enable-smtp --enable-pop
--enable-sidebar --enable-dotlock --disable-fmemopen --with-curses
--with-gnutls --with-gss --with-idn2 --with-mixmaster --with-gsasl
--without-gdbm --without-bdb --without-qdbm --with-tokyocabinet
build_alias=x86_64-linux-gnu 'CFLAGS=-g -O2
-ffile-prefix-map=/build/reproducible-path/mutt-2.2.12=.
-fstack-protector-strong -Wformat -Werror=format-security'
'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2
-ffile-prefix-map=/build/reproducible-path/mutt-2.2.12=.
-fstack-protector-strong -Wformat -Werror=format-security
Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK
+USE_POP +USE_IMAP +USE_SMTP
-USE_SSL_OPENSSL +USE_SSL_GNUTLS -USE_SASL +USE_GSASL +USE_GSS
+HAVE_GETADDRINFO
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +HAVE_FUTIMENS
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME
-EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET
+HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS -HAVE_LIBIDN +HAVE_LIBIDN2 +HAVE_GETSID
+USE_HCACHE
+USE_SIDEBAR +USE_COMPRESSED +USE_INOTIFY
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-15-amd64 (SMP w/48 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE,
Bug#1043320: bash: Background loop with sudo and wait cause terminal problems
FYI, this problem does not happen with sh/dash. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Bug#1043320: bash: Background loop with sudo and wait cause terminal problems
Package: bash
Version: 5.2.15-2+b2
Severity: normal
Dear Maintainer,
* What led up to the situation?
A script that worked fine on Debian 11 caused terminal corruption on Debian 12.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I was able to create a minimal test case to illustrate the problem.
* What was the outcome of this action?
The problem is that output loses carriage returns and echo is turned off for
the terminal on script exit.
* What outcome did you expect instead?
I expected no terminal device corruption. stty sane does fix the terminal
after the failure.
Here is a test case:
#!/bin/bash
for DIR in $(jot 5)
do { echo 1; sudo -u $USER -- echo test > /dev/null; echo 2; } |
cat &
done
wait
Running this on my system outputs the '2' with line feeds and no carriage
returns, and on exit, the terminal has echo turned off. stty sane fixes it.
-- System Information:
Debian Release: 12.1
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-10-amd64 (SMP w/48 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bash depends on:
ii base-files 12.4+deb12u1
ii debianutils 5.7-0.4
ii libc62.36-9+deb12u1
ii libtinfo66.4-4
Versions of packages bash recommends:
ii bash-completion 1:2.11-6
Versions of packages bash suggests:
pn bash-doc
-- Configuration Files:
/etc/bash.bashrc changed:
[ -z "$PS1" ] && return
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
if ! [ -n "${SUDO_USER}" -a -n "${SUDO_PS1}" ]; then
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
if [ -x /usr/lib/command-not-found -o -x
/usr/share/command-not-found/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/lib/command-not-found -- "$1"
return $?
elif [ -x /usr/share/command-not-found/command-not-found ]; then
/usr/share/command-not-found/command-not-found -- "$1"
return $?
else
printf "%s: command not found\n" "$1" >&2
return 127
fi
}
fi
shopt -s histappend
-- no debconf information
Bug#1005069: tracker: Unable to easily disable tracker
Package: tracker Version: 2.3.6-2 Severity: normal Tags: patch Dear Maintainer, I have 2TB of images in the 'Pictures' directory in my home directory. Since upgrading to Bullseye, I found that 'tracker' was using significant CPU, even after days, though the Pictures directory content was unchanged. I can't remove tracker since gnome-flashback-common and gnome-panel depend on it. I tried disabling tracker via systemctl disable and systemctl mask, but it was still running. I tried several suggested gsettings options, but the only one I found that worked was 'gsettings set org.freedesktop.Tracker.Miner.Files index-recursive-directories "[]"'. Tracker wasn't using a huge amoutn of CPU, but on my idle system, it was using the most CPU. I feel it should be easier to disable tracker. -- System Information: Debian Release: 11.2 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tracker depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-2 ii dbus-x11 [dbus-session-bus] 1.12.20-2 ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii libc6 2.31-13+deb11u2 ii libglib2.0-0 2.66.8-1 ii libglib2.0-bin2.66.8-1 ii libicu67 67.1-7 ii libsqlite3-0 3.34.1-3 ii libstemmer0d 2.1.0-1 ii libtracker-control-2.0-0 2.3.6-2 ii libtracker-sparql-2.0-0 2.3.6-2 ii shared-mime-info 2.0-1 Versions of packages tracker recommends: ii tracker-miner-fs 2.3.5-2.1 tracker suggests no packages. -- no debconf information
Bug#613605: patch -b and -V options, overwrites file.orig despite manpage description
I think I understand the manual text now. I read it as create numbered files only if the backup file exists, but I now see it can be read as create numbered files only if other numbered files already exist. I think "have them" is unclear. Maybe the text should be clarified to: Make numbered backups of files that already have numbered backups, otherwise simple backups. This is the default. -- Bruce Momjian http://momjian.us EDB http://enterprisedb.com
Bug#613605: patch -b and -V options, overwrites file.orig despite manpage description
Sorry, but I disagree and think this is a bug in Debian 11, GNU patch
2.7.6. -b forces a backup file, and the manual says of "-V existing":
Make numbered backups of files that already have them, otherwise
simple backups. This is the default.
This example shows that the first patch application creates a backup
file, and the second patch application overwrites it and does not
instead create a numbered file:
$ echo 1 > a
$ cp a b
$ echo 2 >> b
$ diff a b > diff1
$ patch -b -V existing a < diff1
patching file a
$ ls -C
a a.orig b diff1 diff2
$ echo 3 >> b
$ diff a b > diff2
$ patch -b -V existing a < diff2
patching file a
$ ls -C
a a.orig b diff1 diff2
$ cat a.orig
1
2
--
Bruce Momjian http://momjian.us
EDB http://enterprisedb.com
Bug#969559: curl segmentation fauls on any https URL
On Fri, Sep 11, 2020 at 06:28:20PM +0200, Bernhard Übelacker wrote: > Dear Maintainer, hello Bruce Momjian, > with the last informations the issue is perfectly reproducible. > > It looks like a use after free caused by statically stored > function pointers in libengine-pkcs11-openssl / libp11. > > That led to following upstream bug: > https://github.com/OpenSC/libp11/issues/328 > > This got fixed in this commit: > > https://github.com/OpenSC/libp11/commit/e64496a198d4d2eb0310a22dc21be8b81367d319 > > This commit is not yet included in an upstream release tag. > Therefore this error is also visible in current testing. > > I hope it is ok to reassign to libengine-pkcs11-openssl. Yes, thank you for researching this and closing it. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Bug#969559: Info received (Bug#969559: curl segmentation fauls on any https URL)
Oh, the kernel error message might be helpful: curl[4979] general protection ip:7f3a3da00bce sp:7fff5dc217d0 error:0 in libcrypto.so.1.1[7f3a3d8fe000+19e000] -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Bug#969559: curl segmentation fauls on any https URL
On Sun, Sep 6, 2020 at 02:37:22PM +0200, Bernhard Übelacker wrote:
> Hello Bruce Momjian,
> thanks for the details and confirmation.
>
>
> Am 05.09.20 um 17:32 schrieb Bruce Momjian,,,:
> > (gdb) print pmeth->init
> > $1 = (int (*)(EVP_PKEY_CTX *)) 0xf0e0d0c0b0a0908
>
> > gdb) print *pmeth
> > $8 = {pkey_id = 50462976, flags = 117835012, init = 0xf0e0d0c0b0a0908,
> > copy = 0x1716151413121110, cleanup = 0x1f1e1d1c1b1a1918, paramgen_init =
> > 0x98c476a19fc273a5, paramgen = 0x9cc072a593ce7fa9,
>
> The pointer init copy and cleanup are really not looking like usual
> pointers or random ...
>
> > I am using a pkcs11 hardware crypto device, and perhaps it is
> > misconfigured, but it probably shouldn't crash. This might be a library
> > bug, not sure. I will check the pkcs11's configuration now, but it used
> > to work.
>
> But I have no knowledge about such crypto hardware, therefore
> I am not sure if I can be of any more help. Maybe you could
> provide the needed packages, libraries and configuration steps
> that are needed to use such a device of yours when starting with
> a fresh debian installation?
I was just able to reproduce this failure on a fresh install of Debian
10.5/Buster. What I did was just to install pkcs11 support:
apt-get install libengine-pkcs11-openssl
and then modify /etc/ssl/openssl.cnf with the attached patch to use
pkcs11 support; 'curl https://google.com' will then segmentation fault.
This server has no pkcs11 hardware; it is an AWS instance. If you
comment out the line:
pkcs11 = pkcs11_section
curl works again. Thanks for your research so far on this.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
--- /etc/ssl/openssl.cnf.orig 2019-05-30 11:27:48.0 -0400
+++ /etc/ssl/openssl.cnf 2020-09-07 16:02:31.448309714 -0400
@@ -353,6 +353,7 @@
# identifier (optional, default: sha1)
[default_conf]
ssl_conf = ssl_sect
+engines = engine_section
[ssl_sect]
system_default = system_default_sect
@@ -360,3 +361,14 @@
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2
+
+[engine_section]
+pkcs11 = pkcs11_section
+
+[pkcs11_section]
+# https://github.com/openssl/openssl/blob/master/README.ENGINE
+engine_id = pkcs11
+# same as SO_PATH
+dynamic_path = /usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so
+MODULE_PATH = opensc-pkcs11.so
+init = 0
Bug#969559: Info received (Bug#969559: curl segmentation fauls on any https URL)
I have checked my pkcs11 device and it is functioning properly, but curl still crashes. Fortunately I can just use 'wget' until this is fixed. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Bug#969559: curl segmentation fauls on any https URL
On Sat, Sep 5, 2020 at 03:50:20PM +0200, Bernhard Übelacker wrote:
> Dear Maintainer,
> I tried to reproduce this fault, but did not get a segfault.
>
> However, I think the backtrace points to these lines:
>
> (gdb) bt
> #0 0x7769dbce in int_ctx_new () at ../crypto/evp/pmeth_lib.c:160
> #1 0x7769dcfa in EVP_PKEY_CTX_new () at
> ../crypto/evp/pmeth_lib.c:245
> #2 0x77698d44 in do_sigver_init () at ../crypto/evp/m_sigver.c:29
> #3 0x77698eab in EVP_DigestVerifyInit () at
> ../crypto/evp/m_sigver.c:97
> #4 0x775bc7d2 in ASN1_item_verify () at
> ../crypto/asn1/a_verify.c:148
> #5 0x77722490 in X509_verify () at ../crypto/x509/x_all.c:26
> ...
>
>
> https://sources.debian.org/src/openssl/1.1.1d-0+deb10u3/crypto/evp/pmeth_lib.c/#L160
>
> 159 if (pmeth->init) {
> 160 if (pmeth->init(ret) <= 0) {
> 161 ret->pmeth = NULL;
>
> As there is a check for pmeth->init being non-null, I guess
> it contains for some reason an invalid pointer.
>
>
> @Bruce Momjian,
> maybe you could install the following debug symbols packages
> `curl-dbgsym libcurl4-dbgsym libssl1.1-dbgsym` from the dbgsym
> repository described here:
>
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
>
> Then run a new gdb session and when the segfault appears
> please run these commands in gdb:
> print pmeth->init
> bt full 5
Sure, here it is:
(gdb) run https://google.com
Starting program: /usr/bin/curl https://google.com
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x76730700 (LWP 30481)]
[Thread 0x76730700 (LWP 30481) exited]
Thread 1 "curl" received signal SIGSEGV, Segmentation fault.
0x77679bce in int_ctx_new (pkey=pkey@entry=0x556035a0,
e=0x555bd8d0, e@entry=0x0, id=, id@entry=-1) at
../crypto/evp/pmeth_lib.c:160
160 ../crypto/evp/pmeth_lib.c: No such file or directory.
(gdb) print pmeth->init
$1 = (int (*)(EVP_PKEY_CTX *)) 0xf0e0d0c0b0a0908
(gdb) bt full 5
#0 0x77679bce in int_ctx_new (pkey=pkey@entry=0x556035a0,
e=0x555bd8d0, e@entry=0x0, id=, id@entry=-1) at
../crypto/evp/pmeth_lib.c:160
ret = 0x55609810
pmeth = 0x555eaaf0
#1 0x77679cfa in EVP_PKEY_CTX_new
(pkey=pkey@entry=0x556035a0, e=e@entry=0x0) at ../crypto/evp/pmeth_lib.c:245
No locals.
#2 0x77674d44 in do_sigver_init (ctx=ctx@entry=0x556034c0,
pctx=pctx@entry=0x0, type=type@entry=0x777b1fc0 , e=e@entry=0x0,
pkey=pkey@entry=0x556035a0, ver=ver@entry=1)
at ../crypto/evp/m_sigver.c:29
No locals.
#3 0x77674eab in EVP_DigestVerifyInit
(ctx=ctx@entry=0x556034c0, pctx=pctx@entry=0x0,
type=type@entry=0x777b1fc0 , e=e@entry=0x0,
pkey=pkey@entry=0x556035a0)
at ../crypto/evp/m_sigver.c:97
No locals.
#4 0x775987d2 in ASN1_item_verify (it=0x777c3e80
, a=a@entry=0x555ff698,
signature=signature@entry=0x555ff6a8, asn=asn@entry=0x555ff610,
pkey=0x556035a0)
at ../crypto/asn1/a_verify.c:148
type = 0x777b1fc0
ctx = 0x556034c0
buf_in = 0x0
ret = -1
inl = 0
mdnid = 672
pknid = 6
inll = 0
(More stack frames follow...)
I also got this output:
gdb) print *pmeth
$8 = {pkey_id = 50462976, flags = 117835012, init = 0xf0e0d0c0b0a0908,
copy = 0x1716151413121110, cleanup = 0x1f1e1d1c1b1a1918, paramgen_init =
0x98c476a19fc273a5, paramgen = 0x9cc072a593ce7fa9,
keygen_init = 0xdabe4402cda85116, keygen = 0xdeba4006c1a45d1a,
sign_init = 0x681bf10ff0df87ae, sign = 0x6715fc03fbd58ea6, verify_init =
0x924fa56f48f1e16d, verify = 0x8d51b87353ebf875,
verify_recover_init = 0x1799a7c97f8256c6, verify_recover =
0x8b59d56cec4c296f, signctx_init = 0xe7754752753ae23d, signctx =
0x39cf0754b49ebf27, verifyctx_init = 0x48097bc25f90dc0b,
verifyctx = 0x2f1c87c1a44552ad, encrypt_init = 0x87d3b21760a6f545,
encrypt = 0xa820a64334d0d30, decrypt_init = 0x54feb4be1cf7cf7c, decrypt =
0xdfa761d2f0bbe613, derive_init = 0x7929a8e7fefa1af0,
derive = 0x40e6afb34a64a5d7, ctrl = 0x2500f59b71fe4125, ctrl_str =
0xa1c725ad5bb1388, digestsign = 0xe04ff2a999665a4e, digestverify =
0xeacdf8cdaa2b577e, check = 0xe97909bfcc79fc24,
public_check = 0x36de686d3cc21a37, param_check = 0xd, digest_custom =
0x7758ac80 }
(
Bug#969559: curl segmentation fauls on any https URL
Package: curl Version: 7.64.0-4+deb10u1 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** Simply type: $ curl https://google.com Segmentation fault or use any https URL. Here is a backtrace: 0x77679bce in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (gdb) bt #0 0x77679bce in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #1 0x77674d44 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #2 0x775987d2 in ASN1_item_verify () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #3 0x776f8fb4 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #4 0x776fadd6 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #5 0x776fb416 in X509_verify_cert () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #6 0x7780bb88 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #7 0x7782d0f3 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #8 0x7782f6c5 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #9 0x77829143 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #10 0x77814f34 in SSL_do_handshake () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #11 0x77f7f240 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #12 0x77f813f0 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #13 0x77f821da in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #14 0x77f29462 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #15 0x77f4b6fe in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #16 0x77f4caa9 in curl_multi_perform () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #17 0x77f43642 in curl_easy_perform () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #18 0x55569f30 in ?? () #19 0x5556b42a in ?? () #20 0xd8c4 in ?? () #21 0x77b3809b in __libc_start_main (main=0xd770, argc=2, argv=0x7fffded8, init=, fini=, rtld_fini=, stack_end=0x7fffdec8) at ../csu/libc-start.c:308 #22 0xd9da in ?? () *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages curl depends on: ii libc6 2.28-10 ii libcurl4 7.64.0-4+deb10u1 ii zlib1g1:1.2.11.dfsg-1 curl recommends no packages. curl suggests no packages. -- no debconf information
Bug#948238: Need to be 'rw'
Uh, this line in usr.bin.man_filter and usr.bin.man_groff: /var/cache/man/** w, needs to be: /var/cache/man/** rw, -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#948238: More information
I was able to reproduce the failure, so now I have tested fixes. First, I found I had to run 'man' in a terminal with exactly 80 columns. I found this out by using 'man --debug COMMAND' and saw: Terminal width 213 Terminal width 213 not within cat page range [80, 80] indicating the cache will only be used or created with 80 columns. This then generated a 'chown' error, and some apparmor errors. I ended up adding in usr.bin.man_filter and usr.bin.man_groff: /var/cache/man/** w, but I also need to add this to usr.bin.man section: capability chown, capability fowner, capability fsetid, With these changes, man no longer generates errors on the terminal, or apparmor errors in the kernel logs. This was tested by running 'man' as root. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#948238: man-db: man produces apparmor kernel warnings
Ok sounds good, thanks. -- Bruce Momjian br...@momjian.us On Mon, Jan 6, 2020, 5:27 PM Colin Watson wrote: > On Mon, Jan 06, 2020 at 10:07:08PM +, Colin Watson wrote: > > There's already "/var/cache/man/** w" in man_filter, > > In fact, I just noticed that you're running stable, which doesn't have > that fix: > > https://bugs.debian.org/926450 > > https://salsa.debian.org/debian/man-db/commit/e9384c86cddec12c98737afc0f724392497b7b4a > > So the right thing to do is just to issue a stable update with that fix. > I already have such a patch queued up and will try to get round to the > paperwork for it soon. > > -- > Colin Watson [cjwat...@debian.org] > >
Bug#948238: Not repeatable
Unfortunately it only happened the first time, and I can't figure out how to generate the kernel message again. I could run more tests if I knew how to recreate the message. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#948238: man-db: man produces apparmor kernel warnings
Package: man-db
Version: 2.8.5-2
Severity: minor
Tags: patch
Dear Maintainer,
When doing 'man libreoffice' the following kernel messages are generated:
[Sun Jan 5 10:28:57 2020] audit: type=1400 audit(1578238128.275:29):
apparmor="DENIED" operation="file_inherit" profile="man_groff"
name="/var/cache/man/cat1/cattld6Dp" pid=6359 comm="preconv"
requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
[Sun Jan 5 10:28:57 2020] audit: type=1400 audit(1578238128.275:30):
apparmor="DENIED" operation="file_inherit" profile="man_filter"
name="/var/cache/man/cat1/cattld6Dp" pid=6364 comm="gzip" requested_mask="w"
denied_mask="w" fsuid=0 ouid=0
[Sun Jan 5 10:28:57 2020] audit: type=1400 audit(1578238128.279:31):
apparmor="DENIED" operation="file_inherit" profile="man_groff"
name="/var/cache/man/cat1/cattld6Dp" pid=6360 comm="tbl" requested_mask="wr"
denied_mask="wr" fsuid=0 ouid=0
[Sun Jan 5 10:28:57 2020] audit: type=1400 audit(1578238128.283:32):
apparmor="DENIED" operation="file_inherit" profile="man_groff"
name="/var/cache/man/cat1/cattld6Dp" pid=6370 comm="troff" requested_mask="wr"
denied_mask="wr" fsuid=0 ouid=0
It appears apparmor doesn't allow writes by these external tools called by
'man'. The following patch fixes this.
--- ./usr.bin.man.orig 2020-01-05 12:04:13.059106386 -0500
+++ ./usr.bin.man 2020-01-05 12:06:20.037415963 -0500
@@ -59,10 +59,10 @@
/usr/bin/eqn rm,
/usr/bin/grap rm,
/usr/bin/pic rm,
- /usr/bin/preconv rm,
+ /usr/bin/preconv rmw,
/usr/bin/refer rm,
- /usr/bin/tbl rm,
- /usr/bin/troff rm,
+ /usr/bin/tbl rmw,
+ /usr/bin/troff rmw,
/usr/bin/vgrind rm,
/etc/groff/** r,
@@ -82,8 +82,8 @@
# open FDs before execve.
#include
- /{,usr/}bin/bzip2 rm,
- /{,usr/}bin/gzip rm,
+ /{,usr/}bin/bzip2 rmw,
+ /{,usr/}bin/gzip rmw,
/usr/bin/col rm,
/usr/bin/compress rm,
/usr/bin/iconv rm,
-- System Information:
Debian Release: 10.2
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages man-db depends on:
ii bsdmainutils 11.1.2+b1
ii debconf [debconf-2.0] 1.5.71
ii dpkg 1.19.7
ii groff-base 1.22.4-3
ii libc6 2.28-10
ii libgdbm6 1.18.1-4
ii libpipeline1 1.5.1-2
ii libseccomp22.3.3-4
ii zlib1g 1:1.2.11.dfsg-1
man-db recommends no packages.
Versions of packages man-db suggests:
ii apparmor 2.13.2-10
ii firefox-esr [www-browser] 68.2.0esr-1~deb10u1
ii groff 1.22.4-3
ii less 487-0.1+b1
ii lynx [www-browser] 2.8.9rel.1-3
ii w3m [www-browser] 0.5.3-37
-- Configuration Files:
/etc/apparmor.d/usr.bin.man changed:
/usr/bin/man {
#include
# Use a special profile when man calls anything groff-related. We only
# include the programs that actually parse input data in a non-trivial
# way, not wrappers such as groff and nroff, since the latter would need a
# broader profile.
/usr/bin/eqn rmCx -> _groff,
/usr/bin/grap rmCx -> _groff,
/usr/bin/pic rmCx -> _groff,
/usr/bin/preconv rmCx -> _groff,
/usr/bin/refer rmCx -> _groff,
/usr/bin/tbl rmCx -> _groff,
/usr/bin/troff rmCx -> _groff,
/usr/bin/vgrind rmCx -> _groff,
# Similarly, use a special profile when man calls decompressors and other
# simple filters.
/{,usr/}bin/bzip2 rmCx -> _filter,
/{,usr/}bin/gzip rmCx -> _filter,
/usr/bin/col rmCx -> _filter,
/usr/bin/compress rmCx -> _filter,
/usr/bin/iconv rmCx -> _filter,
/usr/bin/lzip.lzip rmCx -> _filter,
/usr/bin/tr rmCx -> _filter,
/usr/bin/xz rmCx -> _filter,
# Allow basically anything in terms of file system access, subject to DAC.
# The purpose of this profile isn't to confine man itself (that might be
# nice in the future, but is tricky since it's quite configurable), but to
# confine the processes it calls that parse untrusted data.
/** mrixwlk,
unix,
capability setuid,
capability setgid,
signal peer=@{profile_name},
signal peer=/usr/bin/man//_groff,
signal peer=/usr/bin/man//_filter,
# Site-specific additions and overrides. See local/README for details.
#include
}
profile man_groff {
#include
# Recent kernels revalidate open FDs, and there are often some still
# open on TTYs. This is temporary until man learns to close irrelevant
# open FDs before execve.
#include
# man always runs its groff pipeline with the input file open on stdin,
# so we can skip .
/usr/bin/eqn rm,
/usr/bin/grap rm,
/usr/bin/pic rm,
/usr/bin/preconv rmw,
/usr/bin/refer rm,
Bug#923051: Update using Buster
I have now upgraded to Buster, and see the same problem. I also see the problem using several text editors, not just with mutt, and with different terminal emulators For example, if I am in vim 7.4 (stock) and use 'h' and 'l' to move back and forth over this text line: xxx , , until 00p I can clearly see it is not redrawing properly. Hopefully this is a more reproducible test case on a more current version of Debian. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#945909: man-db: When outputting 'ps' output from man, apparmor logs an error
Package: man-db
Version: 2.8.5-2
Severity: normal
Tags: patch
Dear Maintainer,
When outputting 'ps' output from man, e.g., 'man -Tps bash', a log apparmor
error is generated in reading /etc/papersize. The log error line shown by
dmesg is:
[1033342.844116] audit: type=1400 audit(1575057625.770:30):
apparmor="DENIED" operation="open" profile="man_groff" name="/etc/papersize"
pid=19233 comm="troff" requested_mask="r" denied_mask="r" fsuid=0
ouid=0
The fix is to add this line to /etc/apparmor.d/usr.bin.man:
profile man_groff {
...
/etc/papersize r,
}
This avoids the error message and allows 'man' to read the file properly.
-- System Information:
Debian Release: 10.2
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages man-db depends on:
ii bsdmainutils 11.1.2+b1
ii debconf [debconf-2.0] 1.5.71
ii dpkg 1.19.7
ii groff-base 1.22.4-3
ii libc6 2.28-10
ii libgdbm6 1.18.1-4
ii libpipeline1 1.5.1-2
ii libseccomp22.3.3-4
ii zlib1g 1:1.2.11.dfsg-1
man-db recommends no packages.
Versions of packages man-db suggests:
ii apparmor 2.13.2-10
ii firefox-esr [www-browser] 68.2.0esr-1~deb10u1
ii groff 1.22.4-3
ii less 487-0.1+b1
ii lynx [www-browser] 2.8.9rel.1-3
ii w3m [www-browser] 0.5.3-37
-- Configuration Files:
/etc/apparmor.d/usr.bin.man changed:
/usr/bin/man {
#include
# Use a special profile when man calls anything groff-related. We only
# include the programs that actually parse input data in a non-trivial
# way, not wrappers such as groff and nroff, since the latter would need a
# broader profile.
/usr/bin/eqn rmCx -> _groff,
/usr/bin/grap rmCx -> _groff,
/usr/bin/pic rmCx -> _groff,
/usr/bin/preconv rmCx -> _groff,
/usr/bin/refer rmCx -> _groff,
/usr/bin/tbl rmCx -> _groff,
/usr/bin/troff rmCx -> _groff,
/usr/bin/vgrind rmCx -> _groff,
# Similarly, use a special profile when man calls decompressors and other
# simple filters.
/{,usr/}bin/bzip2 rmCx -> _filter,
/{,usr/}bin/gzip rmCx -> _filter,
/usr/bin/col rmCx -> _filter,
/usr/bin/compress rmCx -> _filter,
/usr/bin/iconv rmCx -> _filter,
/usr/bin/lzip.lzip rmCx -> _filter,
/usr/bin/tr rmCx -> _filter,
/usr/bin/xz rmCx -> _filter,
# Allow basically anything in terms of file system access, subject to DAC.
# The purpose of this profile isn't to confine man itself (that might be
# nice in the future, but is tricky since it's quite configurable), but to
# confine the processes it calls that parse untrusted data.
/** mrixwlk,
unix,
capability setuid,
capability setgid,
signal peer=@{profile_name},
signal peer=/usr/bin/man//_groff,
signal peer=/usr/bin/man//_filter,
# Site-specific additions and overrides. See local/README for details.
#include
}
profile man_groff {
#include
# Recent kernels revalidate open FDs, and there are often some still
# open on TTYs. This is temporary until man learns to close irrelevant
# open FDs before execve.
#include
# man always runs its groff pipeline with the input file open on stdin,
# so we can skip .
/usr/bin/eqn rm,
/usr/bin/grap rm,
/usr/bin/pic rm,
/usr/bin/preconv rm,
/usr/bin/refer rm,
/usr/bin/tbl rm,
/usr/bin/troff rm,
/usr/bin/vgrind rm,
/etc/groff/** r,
/usr/lib/groff/site-tmac/** r,
/usr/share/groff/** r,
signal peer=/usr/bin/man,
# @{profile_name} doesn't seem to work here.
signal peer=/usr/bin/man//_groff,
#include
}
profile man_filter {
#include
# Recent kernels revalidate open FDs, and there are often some still
# open on TTYs. This is temporary until man learns to close irrelevant
# open FDs before execve.
#include
/{,usr/}bin/bzip2 rm,
/{,usr/}bin/gzip rm,
/usr/bin/col rm,
/usr/bin/compress rm,
/usr/bin/iconv rm,
/usr/bin/lzip.lzip rm,
/usr/bin/tr rm,
/usr/bin/xz rm,
# Manual pages can be more or less anywhere, especially with "man -l", and
# there's no harm in allowing wide read access here since the worst it can
# do is feed data to the invoking man process.
/** r,
signal peer=/usr/bin/man,
# @{profile_name} doesn't seem to work here.
signal peer=/usr/bin/man//_filter,
}
/etc/manpath.config changed:
MANDATORY_MANPATH /usr/man
MANDATORY_MANPATH /usr/share/man
MANDATORY_MANPATH /usr/local/share/man
MANPATH_MAP /bin/usr/share/man
Bug#923051: Acknowledgement (screen doesn't clear the screen for certain UTF8 characters)
I have seen the problem again, this time using the VXConnectbot SSH client on Android, so I think this eliminates the ssh client as the cause. Again, it happens when using 'screen' and mutt's built-in pager, and again when having a UTF8 emoji in the email content. I do not get the failure if I do not use screen. In this case the emoji is on the third page of the email display, and characters from the second email page appear, and again control-L fixes it. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#923051: screen doesn't clear the screen for certain UTF8 characters
Package: screen Version: 4.5.0-6 Severity: normal Tags: l10n Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Jessie did not display emoji UTF8 characters properly in the mutt built-in pager, so I retested with Jessie. * What exactly did you do (or not do) that was effective (or ineffective)? I emailed myself three lines of text: one containing ASCII, one Latin-1 UTF8, and one emoji UTF8. I then viewed the email with the mutt built-in pager. * What was the outcome of this action? The end of the emoji UTF8 line displayed text that appeared on that line before built-in mutt viewer started, meaning the line was not cleared from its previous contents. Here is the actual display: abc ä·öÈ ian oup --- --- The "ian" and "oup" are from the previous mutt display screen listing all my emails in the mailbox, and are not part of the email. Using Control-L makes them properly disappear. Doing this test without 'screen' allowed for proper display. I tested this in Gnome terminal and putty, so I don't think it is the terminal emulator. It might be caused by mutt, but mutt only shows the error when it is run as part of screen. I tested this with screen default, no screenrc file. I am not sure how to test this further but am open to suggestions. * What outcome did you expect instead? I expected no text from the previous mutt screen to appear. *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages screen depends on: ii libc6 2.24-11+deb9u4 ii libpam0g 1.1.8-3.6 ii libtinfo5 6.0+20161126-1+deb9u2 screen recommends no packages. Versions of packages screen suggests: pn byobu | screenie | iselect ii ncurses-term6.0+20161126-1+deb9u2 -- Configuration Files: /etc/screenrc changed [not included] -- no debconf information
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
I have determined that Debian was complaining about my ethernet port because I had flow control enabled on the switch, and the switch was getting easily overwhelmed and hanging, so the Debian resets were valid. Thank you for the research on this. I think you can close this case. --- On Wed, Mar 22, 2017 at 02:42:30AM +, Ben Hutchings wrote: > Control: retitle -1 TX watchdog fires on e1000e interface with flow control > enabled > > On Tue, 2017-03-21 at 18:36 -0400, Bruce Momjian,,, wrote: > > On Tue, Mar 21, 2017 at 04:04:11PM -0400, Bruce Momjian,,, wrote: > > > I think this proves my problems are related to flow control. How would > > > you like to proceed? Is there a patch or change you would like me to > > > test? Just close the ticket? > > > > > > I have a fix, but it is likely others would not know they had this > > > problem unless they were monitoring their kernel logs or their network > > > traffic for lag. > > > > Oh, I should also mention the port that is having problems is connected > > to a NetGear GS108Ev3 switch, with current firmware, version 2.00.09. > > The port connected to my Actiontec FIOS router is not having problems. > > I don't know about any specific bug, but if the switch sends flow > control XOFF frames continually for long enough (usually 5 seconds) > this will trigger the TX watchdog. > > It sounds like your switch implements flow control properly (some > broken switches auto-negotiate it but actually flood flow control > frames). However, if a device on some other port (that also has flow > control enabled) sends XOFF frames continually *and* your server sends > frames that should go to that other port, the switch will do the same > to the server once the switch's internal queue has filled up. > > If the switch has port statistics including numbers of pause frames > then you can see where they are coming from, but I think it doesn't. > Without that information it's going to be hard to tell exactly where > the fault lies. > > The e1000e driver *does* have statistics for pause frames transmitted > and received (run: "ethtool -S eth0| grep flow_control"). If you log > these every second then it should be possible to see what happens > around the time the TX watchdog fires. That could provide some clues > as to whether the NIC is behaving correctly. > > Ben. > > -- > Ben Hutchings > Power corrupts. Absolute power is kind of neat. > - John Lehman, Secretary of the US Navy > 1981-1987 -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
On Thu, Mar 23, 2017 at 03:25:15PM -0400, Bruce Momjian,,, wrote: > I had four more 14 hours later so I created new files that also include > the earlier ones: > > http://momjian.us/expire/eth0/dmesg2.txt > http://momjian.us/expire/eth0/ethtool2.gz > > The last two dmesg lines at 13:29 are me turning of flow control on the > switch so they are not problems. My system is working fine with flow control turned off. What are my next steps? * Additional debugging * Patched or updated Ethernet driver * Try a new Ethernet card * Nothing? -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
On Wed, Mar 22, 2017 at 11:41:57PM -0400, Bruce Momjian,,, wrote: > > OK, I am running this after setting flow control on/default on the > > switch and Debian, and rebooting: > > > > daemon -- sh -c "while :; do date;ethtool -S eth0| grep flow_control; > > sleep 1;done > /root/ethtool" > > > > I will report back with the relevant logging lines once it hangs again. > > OK, I have results of a hang after 24 hours of uptime. The hangs are > listed here via dmesg -T: > > http://momjian.us/expire/eth0/dmesg.txt > > showing the watchdog warning/hang/reset at 23:01 and port hang/reset at > 23:10. > > I have also produced the ethtool -S output every second for the entire > 24-hour period, gziped, at: > > http://momjian.us/expire/eth0/ethtool.gz > > You will see reception of a large number of rx_flow_control_xoff > messages about 50 minutes before the hangs, and just before the hangs. I had four more 14 hours later so I created new files that also include the earlier ones: http://momjian.us/expire/eth0/dmesg2.txt http://momjian.us/expire/eth0/ethtool2.gz The last two dmesg lines at 13:29 are me turning of flow control on the switch so they are not problems. -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
On Tue, Mar 21, 2017 at 11:08:34PM -0400, Bruce Momjian,,, wrote: > > The e1000e driver *does* have statistics for pause frames transmitted > > and received (run: "ethtool -S eth0| grep flow_control"). If you log > > these every second then it should be possible to see what happens > > around the time the TX watchdog fires. That could provide some clues > > as to whether the NIC is behaving correctly. > > OK, I am running this after setting flow control on/default on the > switch and Debian, and rebooting: > > daemon -- sh -c "while :; do date;ethtool -S eth0| grep flow_control; > sleep 1;done > /root/ethtool" > > I will report back with the relevant logging lines once it hangs again. OK, I have results of a hang after 24 hours of uptime. The hangs are listed here via dmesg -T: http://momjian.us/expire/eth0/dmesg.txt showing the watchdog warning/hang/reset at 23:01 and port hang/reset at 23:10. I have also produced the ethtool -S output every second for the entire 24-hour period, gziped, at: http://momjian.us/expire/eth0/ethtool.gz You will see reception of a large number of rx_flow_control_xoff messages about 50 minutes before the hangs, and just before the hangs. -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
On Wed, Mar 22, 2017 at 02:42:30AM +, Ben Hutchings wrote: > Control: retitle -1 TX watchdog fires on e1000e interface with flow control > enabled > > On Tue, 2017-03-21 at 18:36 -0400, Bruce Momjian,,, wrote: > > On Tue, Mar 21, 2017 at 04:04:11PM -0400, Bruce Momjian,,, wrote: > > > I think this proves my problems are related to flow control. How would > > > you like to proceed? Is there a patch or change you would like me to > > > test? Just close the ticket? > > > > > > I have a fix, but it is likely others would not know they had this > > > problem unless they were monitoring their kernel logs or their network > > > traffic for lag. > > > > Oh, I should also mention the port that is having problems is connected > > to a NetGear GS108Ev3 switch, with current firmware, version 2.00.09. > > The port connected to my Actiontec FIOS router is not having problems. > > I don't know about any specific bug, but if the switch sends flow > control XOFF frames continually for long enough (usually 5 seconds) > this will trigger the TX watchdog. Makes sense. > It sounds like your switch implements flow control properly (some > broken switches auto-negotiate it but actually flood flow control > frames). However, if a device on some other port (that also has flow If I turn off flow control on the switch port, and leave the Debian server at defaults, the Debian port automatically turns off flow control, which must be what 'autoneg' is meant to do. > control enabled) sends XOFF frames continually *and* your server sends > frames that should go to that other port, the switch will do the same > to the server once the switch's internal queue has filled up. What I could do it to turn off flow control on all switch ports _except_ the Debian server. The switch has per-port flow control management control. > If the switch has port statistics including numbers of pause frames > then you can see where they are coming from, but I think it doesn't. > Without that information it's going to be hard to tell exactly where > the fault lies. Yeah, I don't see flow control stats on the switch, just CRC error reporting. > The e1000e driver *does* have statistics for pause frames transmitted > and received (run: "ethtool -S eth0| grep flow_control"). If you log > these every second then it should be possible to see what happens > around the time the TX watchdog fires. That could provide some clues > as to whether the NIC is behaving correctly. OK, I am running this after setting flow control on/default on the switch and Debian, and rebooting: daemon -- sh -c "while :; do date;ethtool -S eth0| grep flow_control; sleep 1;done > /root/ethtool" I will report back with the relevant logging lines once it hangs again. Thanks. -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
On Tue, Mar 21, 2017 at 04:04:11PM -0400, Bruce Momjian,,, wrote: > I think this proves my problems are related to flow control. How would > you like to proceed? Is there a patch or change you would like me to > test? Just close the ticket? > > I have a fix, but it is likely others would not know they had this > problem unless they were monitoring their kernel logs or their network > traffic for lag. Oh, I should also mention the port that is having problems is connected to a NetGear GS108Ev3 switch, with current firmware, version 2.00.09. The port connected to my Actiontec FIOS router is not having problems. -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
On Sat, Mar 18, 2017 at 06:33:30PM -0400, Bruce Momjian,,, wrote: > On Sat, Mar 18, 2017 at 06:09:33PM -0400, Bruce Momjian,,, wrote: > > On Sat, Mar 18, 2017 at 10:06:53PM +, Ben Hutchings wrote: > > > > It seems nothing changed. > > > > > > Try: > > > ethtool -A eth0 rx off tx off autoneg off > > > instead. > > > > OK, that worked: > > > > $ ethtool -A eth0 rx off tx off autoneg off > > $ ethtool -a eth0 > > Pause parameters for eth0: > > Autonegotiate: off > > RX: off > > TX: off > > > > I will report back as soon as another failure happens, or doesn't > > happen. :-) Thanks. > > I turned off flow control on the Debian server _and_ the switch port, > because I am told they should match. I will report back. OK, I turned off flow control, rebooted, and ran for 48 hours with no problems. I then turned on flow control (the default), rebooted, and after 21 hours saw a failure, then two minutes later, another one. I think this proves my problems are related to flow control. How would you like to proceed? Is there a patch or change you would like me to test? Just close the ticket? I have a fix, but it is likely others would not know they had this problem unless they were monitoring their kernel logs or their network traffic for lag. -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
On Sat, Mar 18, 2017 at 06:09:33PM -0400, Bruce Momjian,,, wrote: > On Sat, Mar 18, 2017 at 10:06:53PM +, Ben Hutchings wrote: > > > It seems nothing changed. > > > > Try: > > ethtool -A eth0 rx off tx off autoneg off > > instead. > > OK, that worked: > > $ ethtool -A eth0 rx off tx off autoneg off > $ ethtool -a eth0 > Pause parameters for eth0: > Autonegotiate: off > RX: off > TX: off > > I will report back as soon as another failure happens, or doesn't > happen. :-) Thanks. I turned off flow control on the Debian server _and_ the switch port, because I am told they should match. I will report back. -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
On Sat, Mar 18, 2017 at 10:06:53PM +, Ben Hutchings wrote: > On Sat, Mar 18, 2017 at 05:10:50PM -0400, Bruce Momjian,,, wrote: > [...] > > I then ran: > > > > $ ethtool -A eth0 rx off tx off > > > > $ ethtool -a eth0 > > Pause parameters for eth0: > > Autonegotiate: on > > RX: on > > TX: on > > > > It seems nothing changed. > > Try: > ethtool -A eth0 rx off tx off autoneg off > instead. OK, that worked: $ ethtool -A eth0 rx off tx off autoneg off $ ethtool -a eth0 Pause parameters for eth0: Autonegotiate: off RX: off TX: off I will report back as soon as another failure happens, or doesn't happen. :-) Thanks. > > > Have you tried a newer kernel version? Linux 4.9 is available in > > > jessie-backports. > > > > Wow, that seems more risky than just buying a dual-port PCI-E ethernet > > card and using that. FYI, this server is from 2012 so I am worried such > > an upgrade would break things more than fix them. > [...] > > I wasn't suggesting it as a long-term fix but just to check whether a > fix has been implemented. (And I think it is unlikely to break > anything.) Oh, I guess I am not sure how I could test that easily. -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
Here is the dmesg output from just this afternoon: [Mar18 12:40] e1000e :03:00.0 eth0: Reset adapter unexpectedly [ +3.891401] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [Mar18 13:40] e1000e :03:00.0 eth0: Reset adapter unexpectedly [ +3.827380] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [Mar18 14:43] e1000e :03:00.0 eth0: Reset adapter unexpectedly [ +3.871385] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [Mar18 14:47] e1000e :03:00.0 eth0: Reset adapter unexpectedly [ +3.431026] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [Mar18 16:13] e1000e :03:00.0 eth0: Reset adapter unexpectedly [ +3.799385] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [Mar18 17:04] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ +9.870235] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [Mar18 17:05] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [Mar18 17:09] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx which is pretty extreme. Eight resets in five hours! This is a home server (momjian.us) so it isn't like it is pushing huge amounts of data or overloaded. I did so much research on this before reporting it because this is common hardware (SuperMicro) and Intel PRO/1000 ethernet adaptors, which are also popular. There must be something odd about my server, but I have no idea what it is. Also, if I buy a dual PCI-E adaptor, it will also be an Intel PRO/1000. Will I get the same errors on that? -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
On Sat, Mar 18, 2017 at 09:02:10PM +, Ben Hutchings wrote: > Control: retitle -1 TX watchdog fires on e1000e interface > Control: tag -1 moreinfo > > Please don't confuse e1000 and e1000e; they are quite different drivers > for different chips. Oh, thanks for the fix. I think I used e1000 so it would match a kernel file when I entered the bug report. You are right that e1000e is what the kernel reports on the error lines: [ 1351.850362] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out ^^ > Does it help if you disable flow control by running: > > ethtool -A eth0 rx off tx off > > (Check the current settings first by running 'ethtool -a eth0'.) Current settings: $ ethtool -a eth0 Pause parameters for eth0: Autonegotiate: on RX: on TX: on I then ran: $ ethtool -A eth0 rx off tx off $ ethtool -a eth0 Pause parameters for eth0: Autonegotiate: on RX: on TX: on It seems nothing changed. > Have you tried a newer kernel version? Linux 4.9 is available in > jessie-backports. Wow, that seems more risky than just buying a dual-port PCI-E ethernet card and using that. FYI, this server is from 2012 so I am worried such an upgrade would break things more than fix them. If there is no known fix I think that will be my next try, in a long list of many attempts to fix this. -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
Here is a more complete dmesg output with a few resets included at the bottom. You can see there is 14 minutes between the resets: [Mar18 12:26] [ cut here ] [ +0.19] WARNING: CPU: 0 PID: 0 at /build/linux-GU1w8g/linux-3.16.39/net/sched/sch_generic.c:264 dev_watchdog+0x236/0x240() [ +0.04] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out [ +0.02] Modules linked in: binfmt_misc cpufreq_stats cpufreq_conservative cpufreq_powersave cpufreq_userspace cfg80211 rfkill nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc pl2303 usbserial intel_powerclamp coretemp kvm_intel serio_raw kvm nvidia(PO) drm snd_hda_codec_realtek snd_hda_codec_generic iTCO_wdt iTCO_vendor_support snd_hda_intel evdev pcspkr lpc_ich snd_hda_controller snd_hda_codec mfd_core i2c_i801 i2c_core snd_hwdep snd_pcm snd_timer ioatdma snd soundcore button i7core_edac shpchp acpi_cpufreq edac_core dca processor thermal_sys loop firewire_sbp2 fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid hid usb_storage sd_mod crc_t10dif sg crct10dif_generic sr_mod crct10dif_common cdrom ata_generic crc32c_intel ata_piix psmouse uhci_hcd [ +0.75] ehci_pci libata e1000e ehci_hcd firewire_ohci usbcore ptp firewire_core scsi_mod crc_itu_t pps_core usb_common [ +0.13] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P O 3.16.0-4-amd64 #1 Debian 3.16.39-1 [ +0.09] Hardware name: Supermicro X8DA3/X8DA3, BIOS 2.1a 04/06/2012 [ +0.05] 81514c11 88033fc03e28 0009 [ +0.03] 81068867 88033fc03e78 0001 [ +0.09] 88063042 810688cc 81777e40 [ +0.04] Call Trace: [ +0.02][] ? dump_stack+0x5d/0x78 [ +0.14] [] ? warn_slowpath_common+0x77/0x90 [ +0.03] [] ? warn_slowpath_fmt+0x4c/0x50 [ +0.07] [] ? dev_watchdog+0x236/0x240 [ +0.04] [] ? dev_graft_qdisc+0x70/0x70 [ +0.05] [] ? call_timer_fn+0x31/0x140 [ +0.03] [] ? dev_graft_qdisc+0x70/0x70 [ +0.04] [] ? run_timer_softirq+0x1e9/0x2f0 [ +0.05] [] ? __do_softirq+0xf1/0x2d0 [ +0.03] [] ? irq_exit+0x95/0xa0 [ +0.05] [] ? smp_apic_timer_interrupt+0x40/0x50 [ +0.04] [] ? apic_timer_interrupt+0x6d/0x80 [ +0.01][] ? __hrtimer_start_range_ns+0x1cd/0x3a0 [ +0.08] [] ? cpuidle_enter_state+0x4f/0xc0 [ +0.03] [] ? cpuidle_enter_state+0x48/0xc0 [ +0.05] [] ? cpu_startup_entry+0x328/0x470 [ +0.08] [] ? start_kernel+0x497/0x4a2 [ +0.03] [] ? set_init_arg+0x4e/0x4e [ +0.03] [] ? early_idt_handler_array+0x120/0x120 [ +0.03] [] ? x86_64_start_kernel+0x14d/0x15c [ +0.05] ---[ end trace 09366cbabe9552a8 ]--- --> [ +0.18] e1000e :03:00.0 eth0: Reset adapter unexpectedly --> [ +3.963164] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx --> [Mar18 12:40] e1000e :03:00.0 eth0: Reset adapter unexpectedly --> [ +3.891401] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bug#858125: e1000: ethernet interface hangs occasionally, kernel reports hang
Package: src:linux Version: 3.16.39-1 Severity: critical File: e1000 Justification: breaks unrelated software Dear Maintainer, I have had intermittent hangs of my two built-in ethernet interfaces since switching from 100Mb ethernet to 1Gb ethernet. During the hangs, no traffic passes through the port. This has been happening since August 2016 and the hangs are 20-60 seconds. Sometimes the hangs happen every half hour, other times I can go days with no hang, but the hangs are becoming more frequent. Sometimes the hangs report this kernel message: kernel: [96085.866650] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx but other times there is more detail: Mar 18 11:20:13 momjian kernel: [ 2537.679019] [ cut here ] Mar 18 11:20:13 momjian kernel: [ 2537.679031] WARNING: CPU: 0 PID: 0 at /build/linux-GU1w8g/linux-3.16.39/net/sched/sch_generic.c:264 dev_watchdog+0x236/0x240() Mar 18 11:20:13 momjian kernel: [ 2537.679034] NETDEV WATCHDOG: eth1 (e1000e): transmit queue 0 timed out Mar 18 11:20:13 momjian kernel: [ 2537.679035] Modules linked in: cpufreq_stats cpufreq_conservative cpufreq_powersave cpufreq_userspace cfg80211 rfkill binfmt_misc nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc pl2303 usbserial iTCO_wdt iTCO_vendor_support nvidia(PO) intel_powerclamp coretemp pcspkr kvm_intel i2c_i801 kvm snd_hda_codec_realtek drm snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec evdev serio_raw i2c_core snd_hwdep lpc_ich snd_pcm mfd_core snd_timer button i7core_edac snd ioatdma soundcore edac_core shpchp acpi_cpufreq dca processor thermal_sys loop firewire_sbp2 fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid usb_storage hid sg sr_mod cdrom sd_mod crc_t10dif crct10dif_generic crct10dif_common ata_generic crc32c_intel ata_piix ehci_pci uhci_hcd psmouse libata ehci_hcd firewire_ohci e1000e usbcore ptp firewire_core scsi_mod pps_core crc_itu_t usb_common Mar 18 11:20:13 momjian kernel: [ 2537.679107] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P O 3.16.0-4-amd64 #1 Debian 3.16.39-1 Mar 18 11:20:13 momjian kernel: [ 2537.679109] Hardware name: Supermicro X8DA3/X8DA3, BIOS 2.1a04/06/2012 Mar 18 11:20:13 momjian kernel: [ 2537.679111] 81514c11 88033fc03e28 0009 Mar 18 11:20:13 momjian kernel: [ 2537.679114] 81068867 88033fc03e78 0001 Mar 18 11:20:13 momjian kernel: [ 2537.679117] 880330d2 810688cc 81777e40 Mar 18 11:20:13 momjian kernel: [ 2537.679121] Call Trace: Mar 18 11:20:13 momjian kernel: [ 2537.679123] [] ? dump_stack+0x5d/0x78 Mar 18 11:20:13 momjian kernel: [ 2537.679133] [] ? warn_slowpath_common+0x77/0x90 Mar 18 11:20:13 momjian kernel: [ 2537.679137] [] ? warn_slowpath_fmt+0x4c/0x50 Mar 18 11:20:13 momjian kernel: [ 2537.679141] [] ? mod_timer+0xf5/0x200 Mar 18 11:20:13 momjian kernel: [ 2537.679148] [] ? dev_watchdog+0x236/0x240 Mar 18 11:20:13 momjian kernel: [ 2537.679152] [] ? dev_graft_qdisc+0x70/0x70 Mar 18 11:20:13 momjian kernel: [ 2537.679155] [] ? call_timer_fn+0x31/0x140 Mar 18 11:20:13 momjian kernel: [ 2537.679158] [] ? dev_graft_qdisc+0x70/0x70 Mar 18 11:20:13 momjian kernel: [ 2537.679162] [] ? run_timer_softirq+0x1e9/0x2f0 Mar 18 11:20:13 momjian kernel: [ 2537.679165] [] ? __do_softirq+0xf1/0x2d0 Mar 18 11:20:13 momjian kernel: [ 2537.679168] [] ? irq_exit+0x95/0xa0 Mar 18 11:20:13 momjian kernel: [ 2537.679172] [] ? smp_apic_timer_interrupt+0x40/0x50 Mar 18 11:20:13 momjian kernel: [ 2537.679177] [] ? apic_timer_interrupt+0x6d/0x80 Mar 18 11:20:13 momjian kernel: [ 2537.679178] [] ? get_next_timer_interrupt+0x1d6/0x250 Mar 18 11:20:13 momjian kernel: [ 2537.679185] [] ? cpuidle_enter_state+0x4f/0xc0 Mar 18 11:20:13 momjian kernel: [ 2537.679188] [] ? cpuidle_enter_state+0x48/0xc0 Mar 18 11:20:13 momjian kernel: [ 2537.679193] [] ? cpu_startup_entry+0x328/0x470 Mar 18 11:20:13 momjian kernel: [ 2537.679197] [] ? start_kernel+0x497/0x4a2 Mar 18 11:20:13 momjian kernel: [ 2537.679200] [] ? set_init_arg+0x4e/0x4e Mar 18 11:20:13 momjian kernel: [ 2537.679203] [] ? early_idt_handler_array+0x120/0x120 Mar 18 11:20:13 momjian kernel: [ 2537.679207] [] ? x86_64_start_kernel+0x14d/0x15c Mar 18 11:20:13 momjian kernel: [ 2537.679209] ---[ end trace 927f39a58f3280de ]--- Things I have tried to fix it: * switched interface ports; the hang moved to the new port * switched from Cat5e to Cat6 cable * upgraded the motherboard firmware * disabled TCP segmentation offload via ethtool -K eth0 tso off and ethtool -K
Bug#811097: /usr/sbin/dhcpd: Today my dhcp server stopped working and could not be restarted
It must be this set of updates applied last night that did it: isc-dhcp-client isc-dhcp-common isc-dhcp-server openssh-client openssh-server -- Bruce Momjian <br...@momjian.us>http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
Bug#811097: /usr/sbin/dhcpd: Today my dhcp server stopped working and could not be restarted
Package: isc-dhcp-server Version: 4.1.1-P1-15+squeeze9 Severity: critical File: /usr/sbin/dhcpd Justification: breaks unrelated software dhcpd stopped working today and could not be restarted with 'service isc-dhcp-server restart'. It reported a configuration check failure but the configuration file had not been modified for months. I found this also reported here: https://lists.debian.org/debian-user/2016/01/msg00675.html Adding a symlink from /etc/dhcp/dhcpd.conf to /etc/ fixed the problem and allowed the service to start. -- System Information: Debian Release: 6.0.10 APT prefers squeeze-lts APT policy: (500, 'squeeze-lts'), (500, 'oldoldstable-updates'), (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages isc-dhcp-server depends on: ii debconf [debconf-2. 1.5.36.1 Debian configuration management sy ii debianutils 3.4 Miscellaneous utilities specific t ii isc-dhcp-common 4.1.1-P1-15+squeeze9 common files used by all the isc-d ii libc6 2.11.3-4+deb6u8 Embedded GNU C Library: Shared lib ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip isc-dhcp-server recommends no packages. Versions of packages isc-dhcp-server suggests: pn isc-dhcp-server-ldap (no description available) -- Configuration Files: /etc/dhcp/dhcpd.conf changed [not included] -- debconf information excluded
Bug#791469: closed by Raphaël Hertzog hert...@debian.org (Bug#791469: fixed in aptdaemon 0.31+bzr413-1.1+deb6u2)
4aa48860f461fa3b0a47edff944e0a37f28b18a7 168044 aptdaemon_0.31+bzr413-1.1+deb6u2_all.deb bbc8f0e12747c9a9a1d82af22fb6f44eed56d62c 59110 python-aptdaemon_0.31+bzr413-1.1+deb6u2_all.deb 182063ab773d07ec8ed507be32bafe32cd1ab18e 197068 python-aptdaemon-gtk_0.31+bzr413-1.1+deb6u2_all.deb Checksums-Sha256: dcebeef0e76a5e8eb78c1fdd0e0bd1b9cc43221687708da50c21d0eb04db 1699 aptdaemon_0.31+bzr413-1.1+deb6u2.dsc aad690b01816d5635a3d89ec90938c192c37de35e2f41cc46c6cd0f6d7410c56 9790 aptdaemon_0.31+bzr413-1.1+deb6u2.debian.tar.gz 2268b8333b086171b5247077caa50ee9fe2cb5876b75ee9c082520fd39b301d6 168044 aptdaemon_0.31+bzr413-1.1+deb6u2_all.deb 6172a41a6dcf71a8a75aae2cd549c1a2a6874618ba89c05477fef2c257bf8fce 59110 python-aptdaemon_0.31+bzr413-1.1+deb6u2_all.deb d368018fbf97372546867b457402888cce30b137242beca5114cb462e821323a 197068 python-aptdaemon-gtk_0.31+bzr413-1.1+deb6u2_all.deb Files: ee26edc3cb03f96534412d787409e30c 1699 admin extra aptdaemon_0.31+bzr413-1.1+deb6u2.dsc 98d52fb27ff37fa8a277642c3148df15 9790 admin extra aptdaemon_0.31+bzr413-1.1+deb6u2.debian.tar.gz ff8382ba2bba31d5c99dd5e15fc978d9 168044 admin extra aptdaemon_0.31+bzr413-1.1+deb6u2_all.deb c351a06fcb1dd47d6ceb6c2b767d03f5 59110 python extra python-aptdaemon_0.31+bzr413-1.1+deb6u2_all.deb 906f9b60ba329f02edb8813faae94e1a 197068 python extra python-aptdaemon-gtk_0.31+bzr413-1.1+deb6u2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Signed by Raphael Hertzog iQEcBAEBCAAGBQJVmjhPAAoJEAOIHavrwpq51PEIAKjetWUH6qfkmLYrg8jFNrWy Wuf98kYhHGPmd1JO5tc+bFJrbIXEChTd6WerOXl1fuzY8fGZ2Egth5HGb0Xo+neL 1BhAhb9k1UrRRaAwwSoFL4a5oWPyhih1/6wsYOwG5mfHs5NEjlcOTQIRhqKtCG32 jBdH9azgRw7mWGxGZHOIng1IjrmauPhDf018SXbB0Y8yhtIfFjb38/uGUPyfZcP4 /dKikrEB12H2aRCxeG+LvjGIxzz/CSIgGOqPWdVSvehu7fYfYxQBwBHZEwrrtYQs b0M5XQaqMv+vo5PG/xV8L/wta9co2+M7TbjTrwnvC32bT4/fElStuIlxrICAYBA= =yqjt -END PGP SIGNATURE- Received: (at submit) by bugs.debian.org; 5 Jul 2015 13:06:47 + X-Spam-Checker-Version: SpamAssassin 3.4.0-bugs.debian.org_2005_01_02 (2014-02-07) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-12.5 required=4.0 tests=BAYES_00,FOURLA,HAS_PACKAGE, RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,XMAILER_REPORTBUG autolearn=ham autolearn_force=no version=3.4.0-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0. Tokens: new, 18; hammy, 150; neutral, 521; spammy, 0. spammytokens: hammytokens:0.000-+--UD:4.dfsg-3, 0.000-+--UD:3.4.dfsg-3, 0.000-+--UD:2.3.4.dfsg-3, 0.000-+--1.2.3.4.dfsg-3, 0.000-+--UD:1.2.3.4.dfsg-3 Return-path: br...@momjian.us Received: from momjian.us ([72.94.173.45]) by buxtehude.debian.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from br...@momjian.us) id 1ZBjd9-0004Tl-5s for sub...@bugs.debian.org; Sun, 05 Jul 2015 13:06:47 + Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from br...@momjian.us) id 1ZBjd7-tl-Fo; Sun, 05 Jul 2015 09:06:45 -0400 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Bruce Momjian,,, br...@momjian.us To: Debian Bug Tracking System sub...@bugs.debian.org Subject: apt-get upgrade generates Python errors Message-ID: 20150705130645.2834.57771.report...@momjian.us X-Mailer: reportbug 4.12.6 Date: Sun, 05 Jul 2015 09:06:45 -0400 Delivered-To: sub...@bugs.debian.org Package: apt Version: 0.8.10.3+squeeze7 Severity: grave Justification: renders package unusable Running apt-get upgrade or apt-get purge generates this Python error: Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 3 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue [Y/n]? y Setting up python-aptdaemon (0.31+bzr413-1.1+deb6u1) ... /usr/lib/python2.5/site-packages/aptdaemon/worker.py:811: Warning: 'with' will become a reserved keyword in Python 2.6 Compiling /usr/lib/python2.5/site-packages/aptdaemon/worker.py ... File /usr/lib/python2.5/site-packages/aptdaemon/worker.py, line 811 with set_euid_egid(trans.uid, trans.gid): ^ SyntaxError: invalid syntax pycentral: pycentral pkginstall: error byte-compiling files (12) pycentral pkginstall: error byte-compiling files (12) dpkg: error processing python-aptdaemon (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports dpkg: dependency problems prevent configuration of aptdaemon: aptdaemon depends on python-aptdaemon (= 0.31+bzr413-1.1+deb6u1); however: Package python-aptdaemon
Bug#791469: apt-get upgrade generates Python errors
Package: apt Version: 0.8.10.3+squeeze7 Severity: grave Justification: renders package unusable Running apt-get upgrade or apt-get purge generates this Python error: Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 3 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue [Y/n]? y Setting up python-aptdaemon (0.31+bzr413-1.1+deb6u1) ... /usr/lib/python2.5/site-packages/aptdaemon/worker.py:811: Warning: 'with' will become a reserved keyword in Python 2.6 Compiling /usr/lib/python2.5/site-packages/aptdaemon/worker.py ... File /usr/lib/python2.5/site-packages/aptdaemon/worker.py, line 811 with set_euid_egid(trans.uid, trans.gid): ^ SyntaxError: invalid syntax pycentral: pycentral pkginstall: error byte-compiling files (12) pycentral pkginstall: error byte-compiling files (12) dpkg: error processing python-aptdaemon (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports dpkg: dependency problems prevent configuration of aptdaemon: aptdaemon depends on python-aptdaemon (= 0.31+bzr413-1.1+deb6u1); however: Package python-aptdaemon is not configured yet. dpkg: error processing aptdaemon (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of python-aptdaemon-gtk: python-aptdaemon-gtk depends on python-aptdaemon (= 0.31+bzr413-1.1+deb6u1); however: Package python-aptdaemon is not configured yet. dpkg: error processing python-aptdaemon-gtk (--configure): dependency problems - leaving unconfigured configured to not write apport reports configured to not write apport reports Errors were encountered while processing: python-aptdaemon aptdaemon python-aptdaemon-gtk E: Sub-process /usr/bin/dpkg returned an error code (1) The upgrade or purge fails. -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends true; APT::Install-Suggests 0; APT::Acquire ; APT::Acquire::Translation environment; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image.*; APT::NeverAutoRemove:: ^kfreebsd-image.*; APT::NeverAutoRemove:: ^linux-restricted-modules.*; APT::NeverAutoRemove:: ^linux-ubuntu-modules-.*; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Periodic ; APT::Periodic::Update-Package-Lists 1; APT::Periodic::Download-Upgradeable-Packages 0; APT::Periodic::AutocleanInterval 0; APT::Update ; APT::Update::Post-Invoke ; APT::Update::Post-Invoke:: touch /var/lib/apt/periodic/update-success-stamp 2/dev/null || true; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: [ ! -f /var/run/dbus/system_bus_socket ] || /usr/bin/dbus-send --system --dest=org.debian.apt --type=signal /org/debian/apt org.debian.apt.CacheChanged || true; APT::Archives ; APT::Archives::MaxAge 30; APT::Archives::MinAge 2; APT::Archives::MaxSize 500; Dir /; Dir::State var/lib/apt/; Dir::State::lists lists/; Dir::State::cdroms cdroms.list; Dir::State::mirrors mirrors/; Dir::State::extended_states extended_states; Dir::State::status /var/lib/dpkg/status; Dir::Cache var/cache/apt/; Dir::Cache::archives archives/; Dir::Cache::srcpkgcache srcpkgcache.bin; Dir::Cache::pkgcache pkgcache.bin; Dir::Etc etc/apt/; Dir::Etc::sourcelist sources.list; Dir::Etc::sourceparts sources.list.d; Dir::Etc::vendorlist vendors.list; Dir::Etc::vendorparts vendors.list.d; Dir::Etc::main apt.conf; Dir::Etc::netrc auth.conf; Dir::Etc::parts apt.conf.d; Dir::Etc::preferences preferences; Dir::Etc::preferencesparts preferences.d; Dir::Etc::trusted trusted.gpg; Dir::Etc::trustedparts trusted.gpg.d; Dir::Bin ; Dir::Bin::methods /usr/lib/apt/methods; Dir::Bin::dpkg /usr/bin/dpkg; Dir::Media ; Dir::Media::MountPath /media/cdrom; Dir::Log var/log/apt;
Bug#789110: linux-image-2.6.32-5-amd64: Kernel 2.6.32-5-amd64-2.6.32-48squeeze12 causes high load average
On Wed, Jun 17, 2015 at 11:37:00PM +0100, Ben Hutchings wrote: Control: forcermerge 789037 -1 On Wed, 2015-06-17 at 18:14 -0400, Bruce Momjian,,, wrote: Package: linux-2.6 Version: 2.6.32-48squeeze6 Severity: critical Justification: breaks the whole system Twelve hours ago I did a kernal upgrade to 2.6.32-5-amd64-2.6.32-48squeeze12, and since booting that kernel, the load average has steadily increased until it hit 156, cause apache and email software to fail. Rebooting causes the load average to start at zero but increase again. Downgrading to 2.6.32-48squeeze6 fixed the problem. Here is some detail from my kernel log: [...] Sorry, this is fixed in version 2.6.32-48squeeze13 which was released a few hours ago. I can confirm that 2.6.32-48squeeze13 fixes the problem of a growing load average. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789110: linux-image-2.6.32-5-amd64: Kernel 2.6.32-5-amd64-2.6.32-48squeeze12 causes high load average
Package: linux-2.6 Version: 2.6.32-48squeeze6 Severity: critical Justification: breaks the whole system Twelve hours ago I did a kernal upgrade to 2.6.32-5-amd64-2.6.32-48squeeze12, and since booting that kernel, the load average has steadily increased until it hit 156, cause apache and email software to fail. Rebooting causes the load average to start at zero but increase again. Downgrading to 2.6.32-48squeeze6 fixed the problem. Here is some detail from my kernel log: [ 2053.253440] RIP: 0010:[8128c528] [8128c528] tcp_send_fin+0x37/0x1ab [ 2053.253445] RSP: 0018:88032af17f08 EFLAGS: 00010286 [ 2053.253448] RAX: RBX: 880315c33a00 RCX: 88000b01 [ 2053.253451] RDX: 88000c218a98 RSI: 0004 RDI: 880315c33a00 [ 2053.253454] RBP: 880326ecba00 R08: 7ffc70371d78 R09: 7fd9e0519130 [ 2053.253457] R10: 73776f646e695720 R11: 880315c33a00 R12: 880315c33ac8 [ 2053.253460] R13: 88030c09c200 R14: 7fd9de0752f8 R15: 7fd9de073098 [ 2053.253463] FS: 7fd9b740() GS:88000c20() knlGS: [ 2053.253466] CS: 0010 DS: ES: CR0: 80050033 [ 2053.253469] CR2: 005c CR3: 00032ac2 CR4: 06f0 [ 2053.253472] DR0: DR1: DR2: [ 2053.253475] DR3: DR6: 0ff0 DR7: 0400 [ 2053.253478] Process apache2 (pid: 7251, threadinfo 88032af16000, task 88033cb469f0) [ 2053.253480] Stack: [ 2053.253482] 880315c33a00 0002 8129b6af [ 2053.253486] 0 7ffc7037209c 88030c09c200 0001 0001 [ 2053.253491] 0 7ffc70372070 812423e7 7fd9de073098 7fd9de0752f8 [ 2053.253496] Call Trace: [ 2053.253501] [8129b6af] ? inet_shutdown+0x97/0xdd [ 2053.253507] [812423e7] ? sys_shutdown+0x3d/0x5d [ 2053.253512] [81010b22] ? system_call_fastpath+0x16/0x1b [ 2053.253514] Code: 00 00 55 53 49 8b 6c 24 08 48 89 fb 4c 39 e5 48 0f 44 e8 48 85 ed 74 3d 48 83 bf 00 02 00 00 00 75 09 83 3d 4e 3f 27 00 00 74 2a 80 0c 25 5c 00 00 00 01 ff 45 54 ff 83 54 05 00 00 48 83 bb 00 [ 2053.253546] RIP [8128c528] tcp_send_fin+0x37/0x1ab [ 2053.253550] RSP 88032af17f08 [ 2053.253552] CR2: 005c [ 2053.253555] ---[ end trace 72fd0ca540663990 ]--- -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-48squeeze6) (j...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue May 13 16:34:35 UTC 2014 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=e3b10da9-6dc0-45ad-9289-eafe49b21669 ro quiet ** Tainted: P (1) * Proprietary module has been loaded. ** Kernel log: [ 43.163199]domain 2: span 0-15 level NODE [ 43.163202] groups: group 88033e4aa000 cpus 0-3,8-11 (cpu_power = 4712) group 88033e4aa060 cpus 4-7,12-15 (cpu_power = 4712) [ 43.163216] CPU2 attaching sched-domain: [ 43.163220] domain 0: span 2,10 level SIBLING [ 43.163223] groups: group 88000c24fae0 cpus 2 (cpu_power = 589) group 88000c2cfae0 cpus 10 (cpu_power = 589) [ 43.163235] domain 1: span 0-3,8-11 level MC [ 43.163238]groups: group 88000c24fbf0 cpus 2,10 (cpu_power = 1178) group 88000c26fbf0 cpus 3,11 (cpu_power = 1178) group 88000c20fbf0 cpus 0,8 (cpu_power = 1178) group 88000c22fbf0 cpus 1,9 (cpu_power = 1178) [ 43.163259]domain 2: span 0-15 level NODE [ 43.163262] groups: group 88033e4aa000 cpus 0-3,8-11 (cpu_power = 4712) group 88033e4aa060 cpus 4-7,12-15 (cpu_power = 4712) [ 43.163277] CPU3 attaching sched-domain: [ 43.163280] domain 0: span 3,11 level SIBLING [ 43.163284] groups: group 88000c26fae0 cpus 3 (cpu_power = 589) group 88000c2efae0 cpus 11 (cpu_power = 589) [ 43.163294] domain 1: span 0-3,8-11 level MC [ 43.163298]groups: group 88000c26fbf0 cpus 3,11 (cpu_power = 1178) group 88000c20fbf0 cpus 0,8 (cpu_power = 1178) group 88000c22fbf0 cpus 1,9 (cpu_power = 1178) group 88000c24fbf0 cpus 2,10 (cpu_power = 1178) [ 43.163317]domain 2: span 0-15 level NODE [ 43.163321] groups: group 88033e4aa000 cpus 0-3,8-11 (cpu_power = 4712) group 88033e4aa060 cpus 4-7,12-15 (cpu_power = 4712) [ 43.163334] CPU4 attaching sched-domain: [ 43.163337] domain 0: span 4,12 level SIBLING [ 43.163341] groups: group 88034ac0fae0 cpus 4 (cpu_power = 589) group 88034ac8fae0 cpus 12 (cpu_power = 589) [ 43.163351] domain 1: span 4-7,12-15 level MC [ 43.163355]groups: group 88034ac0fbf0 cpus 4,12 (cpu_power = 1178) group 88034ac2fbf0 cpus 5,13 (cpu_power
Bug#789110: linux-image-2.6.32-5-amd64: Kernel 2.6.32-5-amd64-2.6.32-48squeeze12 causes high load average
On Wed, Jun 17, 2015 at 06:46:22PM -0400, Bruce Momjian,,, wrote: On Wed, Jun 17, 2015 at 11:37:00PM +0100, Ben Hutchings wrote: Control: forcermerge 789037 -1 On Wed, 2015-06-17 at 18:14 -0400, Bruce Momjian,,, wrote: Package: linux-2.6 Version: 2.6.32-48squeeze6 Severity: critical Justification: breaks the whole system Twelve hours ago I did a kernal upgrade to 2.6.32-5-amd64-2.6.32-48squeeze12, and since booting that kernel, the load average has steadily increased until it hit 156, cause apache and email software to fail. Rebooting causes the load average to start at zero but increase again. Downgrading to 2.6.32-48squeeze6 fixed the problem. Here is some detail from my kernel log: [...] Sorry, this is fixed in version 2.6.32-48squeeze13 which was released a few hours ago. OK, I don't see it yet --- I assume it will show up the mirrors shortly. Glad you knew about it. I see 2.6.32-48squeeze13 now. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789110: linux-image-2.6.32-5-amd64: Kernel 2.6.32-5-amd64-2.6.32-48squeeze12 causes high load average
On Wed, Jun 17, 2015 at 11:37:00PM +0100, Ben Hutchings wrote: Control: forcermerge 789037 -1 On Wed, 2015-06-17 at 18:14 -0400, Bruce Momjian,,, wrote: Package: linux-2.6 Version: 2.6.32-48squeeze6 Severity: critical Justification: breaks the whole system Twelve hours ago I did a kernal upgrade to 2.6.32-5-amd64-2.6.32-48squeeze12, and since booting that kernel, the load average has steadily increased until it hit 156, cause apache and email software to fail. Rebooting causes the load average to start at zero but increase again. Downgrading to 2.6.32-48squeeze6 fixed the problem. Here is some detail from my kernel log: [...] Sorry, this is fixed in version 2.6.32-48squeeze13 which was released a few hours ago. OK, I don't see it yet --- I assume it will show up the mirrors shortly. Glad you knew about it. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760536: groff: nroff -man can't produce full man page output
On Fri, Sep 5, 2014 at 04:01:31PM +0100, Colin Watson wrote: On Thu, Sep 04, 2014 at 10:28:46PM -0400, Bruce Momjian,,, wrote: The command: zcat /usr/share/man/man3/printf.3.gz| nroff -man produces this as the last line: e, E The double argument is rounded and converted in the style which obviously is not the end of the file. The man file hasn't changed since 2010, so something else must be wrong. Can you reproduce this failure? Well, you're running squeeze; not a lot has changed since 2010. :-) However, I've been unable to reproduce this in a squeeze chroot after installing groff-base, locales, manpages-dev, and vim, generating the en_US.UTF-8 locale, and running your command in that locale. The line after the one you mention includes a non-ASCII character, so doubtless this is some kind of Unicode-related problem. Let's rule out one possibility first: please attach the output of: zcat /usr/share/man/man3/printf.3.gz | groff -mtty-char -Tutf8 -man -Z Actually, I found the cause. I have local macros for AM/PM text, and they are called Am and Pm, with the assumtion that local macros are mixed case. Well, it seems printf has: .if \w'\*(Pm'=0 .ds Pm \(+- which ends up calling my macro which then doesn't end well. :-( Anyway, I have no idea if mixed-case macros are legal in man pages. I will fix it on my end by no including my custom macros when in manual page mode. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760536: groff: nroff -man can't produce full man page output
On Fri, Sep 5, 2014 at 04:01:31PM +0100, Colin Watson wrote: On Thu, Sep 04, 2014 at 10:28:46PM -0400, Bruce Momjian,,, wrote: The command: zcat /usr/share/man/man3/printf.3.gz| nroff -man produces this as the last line: e, E The double argument is rounded and converted in the style which obviously is not the end of the file. The man file hasn't changed since 2010, so something else must be wrong. Can you reproduce this failure? Well, you're running squeeze; not a lot has changed since 2010. :-) However, I've been unable to reproduce this in a squeeze chroot after installing groff-base, locales, manpages-dev, and vim, generating the en_US.UTF-8 locale, and running your command in that locale. The line after the one you mention includes a non-ASCII character, so doubtless this is some kind of Unicode-related problem. Let's rule out one possibility first: please attach the output of: zcat /usr/share/man/man3/printf.3.gz | groff -mtty-char -Tutf8 -man -Z I started thinking this morning that I have a /usr/share/groff/1.20.1/tmac/troffrc file that I added some macros to years ago, and removing my troffrc changes fixes the problem, so I think we can close the bug report. I am right now trying to figure out exactly what it is in my troffrc that are causing this, but the bug is certainly mine. Thanks for checking. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760536: groff: nroff -man can't produce full man page output
Package: groff Version: 1.20.1-10 Severity: normal The command: zcat /usr/share/man/man3/printf.3.gz| nroff -man produces this as the last line: e, E The double argument is rounded and converted in the style which obviously is not the end of the file. The man file hasn't changed since 2010, so something else must be wrong. Can you reproduce this failure? -- System Information: Debian Release: 6.0.10 APT prefers squeeze-lts APT policy: (500, 'squeeze-lts'), (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages groff depends on: ii dpkg 1.15.11Debian package management system ii groff-base1.20.1-10 GNU troff text-formatting system ( ii install-info 4.13a.dfsg.1-6 Manage installed documentation in ii libc6 2.11.3-4+deb6u1Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libice6 2:1.0.6-2 X11 Inter-Client Exchange library ii libsm62:1.1.1-1 X11 Session Management library ii libstdc++64.4.5-8The GNU Standard C++ Library v3 ii libx11-6 2:1.3.3-4+squeeze1 X11 client-side library ii libxaw7 2:1.0.7-1 X11 Athena Widget library ii libxmu6 2:1.0.5-2 X11 miscellaneous utility library ii libxt61:1.0.7-1+squeeze1 X11 toolkit intrinsics library Versions of packages groff recommends: ii ghostscript8.71~dfsg2-9+squeeze1 The GPL Ghostscript PostScript/PDF ii imagemagick8:6.6.0.4-3+squeeze4 image manipulation programs ii libpaper1 1.1.24library for handling paper charact ii netpbm 2:10.0-12.2+b1Graphics conversion tools between ii psutils1.17-27 A collection of PostScript documen groff suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742188: mailutils: Multiple command-line files produce incorrect summary totals
Package: mailutils Version: 1:2.1+dfsg1-7 Severity: normal When supplying multiple mailbox files to 'frm', the summary is cummulative, rather than being reset for each file, e.g.: $ frm -qS /var/mail/bruce Folder contains 1 new message, 4 unread messages, 72 read messages. ^ $ frm -qS /var/mail/bruce /var/mail/bruce /var/mail/bruce: Folder contains 1 new message, 4 unread messages, 72 read messages. /var/mail/bruce: Folder contains 2 new messages, 8 unread messages, 144 read messages. ^ Of course, normally you would two different file names. This behavior is not documented, and is not reflected in the output. -- System Information: Debian Release: 6.0.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mailutils depends on: ii exim4-daemon-light 4.72-6+squeeze3 lightweight Exim MTA (v4) daemon ii guile-1.8-libs 1.8.7+1-3Main Guile libraries ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-4stable1 common error description library ii libfribidi0 0.19.2-1 Free Implementation of the Unicode ii libgcrypt11 1.4.5-2+squeeze1 LGPL Crypto library - runtime libr ii libgdbm31.8.3-9 GNU dbm database routines (runtime ii libgmp3c2 2:4.3.2+dfsg-1 Multiprecision arithmetic library ii libgnutls26 2.8.6-1+squeeze2 the GNU TLS library - runtime libr ii libgpg-error0 1.6-1library for common error values an ii libgsasl7 1.4.4-2 GNU SASL library ii libgssapi-krb5-21.8.3+dfsg-4squeeze7 MIT Kerberos runtime libraries - k ii libidn111.15-2 GNU Libidn library, implementation ii libk5crypto31.8.3+dfsg-4squeeze7 MIT Kerberos runtime libraries - C ii libkrb5-3 1.8.3+dfsg-4squeeze7 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.23-7.3 OpenLDAP libraries ii libltdl72.2.6b-2 A system independent dlopen wrappe ii libmailutils2 1:2.1+dfsg1-7GNU Mail abstraction library ii libmysqlclient165.1.73-1 MySQL database client library ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libntlm01.2-1NTLM authentication library ii libpam0g1.1.1-6.1+squeeze1 Pluggable Authentication Modules l ii libpython2.62.6.6-8+b1 Shared Python runtime library (ver ii libreadline66.1-3GNU readline and history libraries ii libwrap07.6.q-19 Wietse Venema's TCP wrappers libra ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime mailutils recommends no packages. Versions of packages mailutils suggests: pn mailutils-mh none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652990: screen: Cannot bind space to a different action
On Wed, Jan 11, 2012 at 07:00:52PM +0100, Axel Beckert wrote:
I reported it to the GNU Screen developers at
https://savannah.gnu.org/bugs/index.php?35287
I did some more thinking on this and I think I have a conclusion.
First, my initial report was wrong --- typing fast does not trigger the
default action --- it triggers the control-key action for the second
key, e.g. ^A-space yields ^A-control(space), which also happens to be
^@, or the null byte. This probably happens because the control was
down for the ^A, and might pass into the next key.
Second, I notice that they map control(space) to the same action as
space in the default bindings (which were not modified by Debian):
ktab[' '].nr = ktab[Ctrl(' ')].nr =
-
ktab['n'].nr = ktab[Ctrl('n')].nr = RC_NEXT;
Third, because the control-space (^@) is coming from the read() kernel
call (and I don't see them remapping 'read' to their own function), I
realized the problem might not be with screen but perhaps the terminal
driver. However, I tried to reproduce the problem from the command line
by typing ^A-space quickly and did not see that behavior.
I then started to wonder why I had not see this behavior with screen on
my previous BSD system so I booted it up, and found it has exactly the
fix I just discovered, e.g. binding ^@ to the same action as space.
So, I think I have a solution for my problem, and that is to map
control-key to the same action as the non-control key. I see them doing
that in several default screen bindings, and I will just follow that if
I see another key exhibiting this problem.
So, for me, I don't need to peruse this issue further, but am available
if someone else needs help on this. Thanks for looking into this for me.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652990: screen: Cannot bind space to a different action
On Wed, Jan 11, 2012 at 07:00:52PM +0100, Axel Beckert wrote: tag 652990 + confirmed upstream retitle 652990 screen: Binding a key to a different action sometimes still yields the default binding forwarded 652990 https://savannah.gnu.org/bugs/index.php?35287 kthxbye Hi Bruce, thanks for the reminder. Bruce Momjian wrote: I just found the cause of my odd Enter behavior and was about to email an update. It turns out if you press ^A, and then space quickly, you get the (wrong) 'next' behavior, but if press ^A then and then wait for a second and then press space, you get the (right) configured info behavior. [...] Is that reproducible for you? Indeed it is -- despite it happened in only about 10% of my tries to type ^A Space quickly. (Maybe I'm still not typing fast enough all the time. ;-) I'll check later if this still happens with the version of screen in Debian experimental. Any update on this? Yes, and I'm sorry to say that it still happens with the newest upstream version and does not only happen with space. I could also reproduce it with the key c instead. I reported it to the GNU Screen developers at https://savannah.gnu.org/bugs/index.php?35287 Having seen no activity on this, I decided to dig into the code in a serious way. I added some debug statements and put screen in debug mode and found that the read() call in disp_readev_fn() was returning ^@ (the null byte) for space when typed quickly. Here is my debug output: + hit ev fd 4 type 1! size = 4096 char = ^Z len = 1 disp_readev_fn 2 ProcessInput: 1 bytes cmp2 ^Z cmp ^Z ESC[3] complete miss ProcessInput2: 1 bytes - ilen now 1 bytes + hit ev fd 0 type 3! serv_select_fn called waiting for events: - fd 4 type 1 pri 0 - fd 4 type 2 pri 0 - fd 8 type 1 pri 0 - fd 8 type 2 pri 0 - fd 5 type 1 pri 0 - fd 0 type 3 pri -10 - cond ev fd 4 type 2 failed - cond ev fd 8 type 2 failed readfds: 4 5 8 writefds: + hit ev fd 4 type 1! size = 4096 -- char = ^@ len = 1 disp_readev_fn 2 ProcessInput: 1 bytes cmp2 ^@ cmp ^@ ESC[3] complete miss ProcessInput2: 1 bytes - ilen now 1 bytes AclCheckPermCmd(root 0 next) = 0 Now, read() returning a null byte for space is really odd, and I have no idea what would cause that. With that information, I decided to add this to my screenrc: # fix screen bug caused by typing fast, 'space' becomes null byte, 2012-01-16 bind ^@ other This does fix my immediate problem of meta-space not working. I suspect that other cases also might return a null byte, but I am not sure that is a problem for me. I am not clear now if the problem is that type fast causes the default action, or type fast causes 'next' because next is bound to the null byte. Let me know if you want my debug diff but I basically just output the byte the read() returned (assuming size 0). Hopefully this will give someone a place to continue debugging this. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652990: screen: Cannot bind space to a different action
On Fri, Dec 23, 2011 at 04:31:27PM +0100, Axel Beckert wrote: tag 652990 - unreproducible moreinfo kthxbye Hi Bruce, thanks for the followup. Bruce Momjian wrote: I just found the cause of my odd Enter behavior and was about to email an update. It turns out if you press ^A, and then space quickly, you get the (wrong) 'next' behavior, but if press ^A then and then wait for a second and then press space, you get the (right) configured info behavior. [...] Is that reproducible for you? Indeed it is -- despite it happened in only about 10% of my tries to type ^A Space quickly. (Maybe I'm still not typing fast enough all the time. ;-) I'll check later if this still happens with the version of screen in Debian experimental. Any update on this? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655293: grep range matches lowercase characters
Package: grep Version: 2.6.3-3 Severity: normal With LC_ALL undefined, this uppercase pattern doesn't work properly, e.g.: $ echo 'Aa' | grep '[A-Z][A-Z]*$' $ echo 'Ab' | grep '[A-Z][A-Z]*$' .Ab The second entry should not match. If I define LC_ALL=C, it works properly. This was confirmed by users on the IRC debian channel, and they say it is fixed in 'sid'. I tried [:upper:] and it does work: $ echo '\.Ab' | grep '\.[[:upper:]][[:upper:]]*$' $ This looks like a serious issue. IRC folks report it was broken when perl compatibility was added, though I am not using perl compability. They say it works in perl mode, but not in Posix or ERE. This bug report looks similar: http://savannah.gnu.org/bugs/index.php?31389 -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grep depends on: ii dpkg 1.15.8.11 Debian package management system ii install-info 4.13a.dfsg.1-6 Manage installed documentation in ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib grep recommends no packages. Versions of packages grep suggests: ii libpcre3 8.02-1.1 Perl 5 Compatible Regular Expressi -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653631: cups: lpoptions has incorrect manual page
Package: cups Version: 1.4.4-7 Severity: minor The lpoptions manual page says: If no options are specified using the -o option, then the current options for the named printer are reported on the standard output. However, it does not work as documented: $ lpoptions -o Usage: lpoptions [-h server] [-E] -d printer lpoptions [-h server] [-E] [-p printer] -l lpoptions [-h server] [-E] -p printer -o option[=value] ... lpoptions [-h server] [-E] -x printer -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cups depends on: ii adduser 3.112+nmu2 add and remove users and groups ii bc 1.06.95-2The GNU bc arbitrary precision cal ii cups-client 1.4.4-7 Common UNIX Printing System(tm) - ii cups-common 1.4.4-7 Common UNIX Printing System(tm) - ii cups-ppdc 1.4.4-7 Common UNIX Printing System(tm) - ii debconf [debconf-2. 1.5.36.1 Debian configuration management sy ii ghostscript 8.71~dfsg2-9 The GPL Ghostscript PostScript/PDF ii libavahi-client30.6.27-2+squeeze1Avahi client library ii libavahi-common30.6.27-2+squeeze1Avahi common library ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libcups21.4.4-7 Common UNIX Printing System(tm) - ii libcupscgi1 1.4.4-7 Common UNIX Printing System(tm) - ii libcupsdriver1 1.4.4-7 Common UNIX Printing System(tm) - ii libcupsimage2 1.4.4-7 Common UNIX Printing System(tm) - ii libcupsmime11.4.4-7 Common UNIX Printing System(tm) - ii libcupsppdc11.4.4-7 Common UNIX Printing System(tm) - ii libdbus-1-3 1.2.24-4+squeeze1simple interprocess messaging syst ii libgcc1 1:4.4.5-8GCC support library ii libgnutls26 2.8.6-1 the GNU TLS library - runtime libr ii libgssapi-krb5-21.8.3+dfsg-4squeeze2 MIT Kerberos runtime libraries - k ii libijs-0.35 0.35-7 IJS raster image transport protoco ii libkrb5-3 1.8.3+dfsg-4squeeze2 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.23-7.2 OpenLDAP libraries ii libpam0g1.1.1-6.1Pluggable Authentication Modules l ii libpaper1 1.1.24 library for handling paper charact ii libpoppler5 0.12.4-1.2 PDF rendering library ii libslp1 1.2.1-7.8OpenSLP libraries ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libusb-0.1-42:0.1.12-16 userspace USB programming library ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii poppler-utils 0.12.4-1.2 PDF utilitites (based on libpopple ii procps 1:3.2.8-9/proc file system utilities ii ssl-cert1.0.28 simple debconf wrapper for OpenSSL ii ttf-freefont20090104-7 Freefont Serif, Sans and Mono True ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages cups recommends: ii cups-driver-gutenprint 5.2.6-1 printer drivers for CUPS ii foomatic-filters4.0.5-6 OpenPrinting printer support - fil ii ghostscript-cups8.71~dfsg2-9 The GPL Ghostscript PostScript/PDF Versions of packages cups suggests: ii cups-bsd 1.4.4-7Common UNIX Printing System(tm) - pn cups-pdf none (no description available) ii foomatic-db 20100630-1 OpenPrinting printer support - dat ii hplip 3.10.6-2 HP Linux Printing and Imaging Syst ii smbclient 2:3.5.6~dfsg-3squeeze4 command-line SMB/CIFS clients for ii udev 164-3 /dev/ and hotplug management daemo pn xpdf-korean | xpd none (no description available) -- Configuration Files: /etc/cups/cupsd.conf changed: LogLevel warn MaxLogSize 0 SystemGroup lpadmin Port 631 Listen /var/run/cups/cups.sock Browsing On BrowseOrder allow,deny BrowseAllow all BrowseRemoteProtocols CUPS BrowseAddress @LOCAL BrowseLocalProtocols CUPS dnssd DefaultAuthType Basic Location / # Allow shared printing... Order allow,deny Allow @LOCAL /Location Location /admin # Restrict access to the admin pages... Order allow,deny /Location Location /admin/conf AuthType Default Require user @SYSTEM # Restrict access to the configuration files...
Bug#653313: apache2: Bug in mixing of mod_rewrite and directory index
Package: apache2.2-common Version: 2.2.16-6+squeeze4 Severity: normal If I enable mod_rewrite, and access a directory index URL (no index.html), I see this in my server logs: [Mon Dec 26 13:39:48 2011] [error] [client 172.20.1.11] Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden: /usr/share/apache2/icons/text.gif, referer: http://momjian.us/main/writings/ The system is trying to access the images that appear in directory listings, e.g. text.gif. Adding Options +FollowSymLinks in /etc/apache2/sites-enabled/000-default did not help. I had to add it to /etc/apache2/mods-enabled/alias.conf with the attached patch: *** ./alias.conf.orig 2011-12-26 13:56:12.0 -0500 --- ./alias.conf2011-12-26 13:56:57.0 -0500 *** *** 16,21 --- 16,23 Directory /usr/share/apache2/icons Options Indexes MultiViews + # remove log rewrite error for index lookups 2011-12-26 + Options +FollowSymLinks AllowOverride None Order allow,deny Allow from all This eliminated the log error message. _ -- Package-specific info: List of enabled modules from 'apache2 -M': actions* alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi deflate dir env include mime negotiation perl php5 python reqtimeout rewrite setenvif status (A * means that the .conf file for that module is not enabled in /etc/apache2/mods-enabled/) List of enabled php5 extensions: pdo suhosin -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apache2 depends on: ii apache2-mpm-prefork2.2.16-6+squeeze4 Apache HTTP Server - traditional n ii apache2.2-common 2.2.16-6+squeeze4 Apache HTTP Server common files apache2 recommends no packages. apache2 suggests no packages. Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.16-6+squeeze4 utility programs for webservers ii apache2.2-bin 2.2.16-6+squeeze4 Apache HTTP Server common binary f ii libmagic1 5.04-5File type determination library us ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii mime-support 3.48-1MIME files 'mime.types' 'mailcap ii perl 5.10.1-17squeeze2 Larry Wall's Practical Extraction ii procps 1:3.2.8-9 /proc file system utilities -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653171: txt2html: Link dictionaries are ignored
Package: txt2html Version: 2.51-1 Severity: normal Using personal link dictionaries is ignored. You can reproduce it by creating a file called 'link.dict' with contents: /lt;ENTgt;/ -h- XXX and then create a file 'x.txt' with: ENT an then run: txt2html --link link.dict x.txt: You will see: plt;ENTgt;/p while you should see: XXX This worked in older versions of txt2html, and these emails state it worked in 2.46, but not in 2.50: http://tech.groups.yahoo.com/group/txt2html/message/257 http://tech.groups.yahoo.com/group/txt2html/message/258 -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages txt2html depends on: ii libgetopt-argvfile-per 1.11-1Perl module for reading script opt ii libyaml-syck-perl 1.12-1Perl module providing a fast, ligh ii perl 5.10.1-17squeeze2 Larry Wall's Practical Extraction txt2html recommends no packages. Versions of packages txt2html suggests: ii perl-doc 5.10.1-17squeeze2 Perl documentation -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653171: Acknowledgement (txt2html: Link dictionaries are ignored)
Debian Bug Tracking System wrote:
Thank you for filing a new Bug report with Debian.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.
Your message has been sent to the package maintainer(s):
Varun Hiremath va...@debian.org
If you wish to submit further information on this problem, please
send it to 653...@bugs.debian.org.
I have fixed the problem with the attached patch, though I am unclear if
this is the right fix. I am not sure what args() is trying to do.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
*** ./TextToHTML.pm.orig 2011-12-24 11:51:20.0 -0500
--- ./TextToHTML.pm 2011-12-24 20:22:40.0 -0500
***
*** 5291,5297
if (-r $ld)
{
$self-{'make_links'} = 1;
! $self-args(['--links_dictionaries', $ld]);
}
else
{
--- 5291,5297
if (-r $ld)
{
$self-{'make_links'} = 1;
! push(@{$self-{links_dictionaries}}, $ld);
}
else
{
Bug#652990: screen: Cannot bind space to a different action
Axel Beckert wrote: tag 652990 + unreproducible moreinfo kthxbye Hi Bruce, Bruce Momjian,,, wrote: Package: screen Version: 4.0.3-14 Severity: normal I can cannot change the binding of the spacebar in screen. If you start screen with just this configuration file: bind ' ' info you will find that when you start screen, ^A-space will show the window info, but once you press Enter, ^A-space will do 'next screen' and never show info again. I'm sorry, but I can't reproduce this problem. I put bind ' ' info as sole line (with line break at the end) in a .screenrc, started screen, pressed ^A-Space, it worked fine. I then pressed Enter in the shell as well as ^A-Enter, but ^A-Space as well as ^A-Enter continue to show the one line window info. Nothing tries to switch to the next window, i.e. it works fine for me. I tested it on Squeeze amd64 as you seem to have experienced the issue on Squeeze amd64. Maybe there need some additional requirements to be met to run into this issue? I just found the cause of my odd Enter behavior and was about to email an update. It turns out if you press ^A, and then space quickly, you get the (wrong) 'next' behavior, but if press ^A then and then wait for a second and then press space, you get the (right) configured info behavior. I was able to reproduce this same problem with the 'f'/flow binding as well, so I think it might be more widespread than just the binding of the spacebar. Is that reproducible for you? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652990: screen: Cannot bind space to a different action
Axel Beckert wrote: tag 652990 - unreproducible moreinfo kthxbye Hi Bruce, thanks for the followup. Bruce Momjian wrote: I just found the cause of my odd Enter behavior and was about to email an update. It turns out if you press ^A, and then space quickly, you get the (wrong) 'next' behavior, but if press ^A then and then wait for a second and then press space, you get the (right) configured info behavior. [...] Is that reproducible for you? Indeed it is -- despite it happened in only about 10% of my tries to type ^A Space quickly. (Maybe I'm still not typing fast enough all the time. ;-) Well, that is good to hear. I seem to type so fast that it took me two days realize slowing down made it work. ;-) I'll check later if this still happens with the version of screen in Debian experimental. Thanks. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652990: screen: Cannot bind space to a different action
Package: screen Version: 4.0.3-14 Severity: normal I can cannot change the binding of the spacebar in screen. If you start screen with just this configuration file: bind ' ' info you will find that when you start screen, ^A-space will show the window info, but once you press Enter, ^A-space will do 'next screen' and never show info again. This is true even though ^A-? shows space as bound to 'info': infosp i I used 'info' as an example, but there is no action that can be properly bound to space, e.g. 'other'. This worked in older versions of screen. -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages screen depends on: ii dpkg 1.15.8.11 Debian package management system ii install-info 4.13a.dfsg.1-6 Manage installed documentation in ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libncursesw5 5.7+20100313-5 shared libraries for terminal hand ii libpam0g 1.1.1-6.1 Pluggable Authentication Modules l screen recommends no packages. screen suggests no packages. -- Configuration Files: /etc/screenrc changed: deflogin on vbell on defscrollback 1024 bind ^k bind ^\ bind \\ quit bind K kill bind I login on bind O login off bind } history termcapinfo vt100 dl=5\E[M hardstatus off termcapinfo xterm*|rxvt*|kterm*|Eterm* hs:ts=\E]0;:fs=\007:ds=\E]0;\007 hardstatus string %h%? users: %u%? termcapinfo xterm*|linux*|rxvt*|Eterm* OP termcapinfo xterm 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l' defnonblock 5 escape ^zZ bind f bind ^z next bind ' ' info bind - prev bind p screen /letc/hardcopyprint bind x bind ^x bind L reset hardcopy_append on vbell_msg Wuff screen -t login 0 /bin/bash screen -t startup 9 /letc/multi_save -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506196: [BUGS] Debian Bug#506196: postgresql: consume too much power when idle (10 wakeups/second)
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: I think we must blame bgwriter then. I had a look at it some time ago to how hard would it be to remove the useless wakeups and concluded that it wasn't really worth the trouble. I've got similar complaints in the RH/Fedora bugzilla. It's hard to fix in a portable way because of the lack of consistent select/poll semantics across various platforms. See my previous notes about the lack of consistent EINTR behavior and whether we should really be using SA_RESTART. The short answer is don't hold your breath. It'd be nice to have a plan for improving things though. Is this a TODO? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#372115: [BUGS] Bug#372115: Last security update of postgresql-contrib breaks database replication with DBMirror.pl
Patch applied. Thanks. Backpatched back to 7.3.X. --- Martin Pitt wrote: -- Start of PGP signed section. Hi PostgreSQL gurus, hi Olivier, Martin Pitt [2006-06-16 0:15 +0200]: Upstream confirmed my reply in the last mail in [1]: the complete escaping logic in DBMirror.pl is seriously screwew. [1] http://archives.postgresql.org/pgsql-bugs/2006-06/msg00065.php I finally found some time to debug this, and I think I found a better patch than the one you proposed. Mine is still hackish and is still a workaround around a proper quoting solution, but at least it repairs the parsing without introducing the \' quoting again. I consider this a band-aid patch to fix the recent security update. PostgreSQL gurus, would you consider applying this until a better solution is found for DBMirror.pl? Olivier, can you please confirm that the patch works for you, too? Thank you, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates? [ Attachment, skipping... ] -- End of PGP section, PGP failed! -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372115: [BUGS] Bug#372115: Last security update of postgresql-contrib breaks database replication with DBMirror.pl
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Martin Pitt wrote: -- Start of PGP signed section. Hi PostgreSQL gurus, hi Olivier, Martin Pitt [2006-06-16 0:15 +0200]: Upstream confirmed my reply in the last mail in [1]: the complete escaping logic in DBMirror.pl is seriously screwew. [1] http://archives.postgresql.org/pgsql-bugs/2006-06/msg00065.php I finally found some time to debug this, and I think I found a better patch than the one you proposed. Mine is still hackish and is still a workaround around a proper quoting solution, but at least it repairs the parsing without introducing the \' quoting again. I consider this a band-aid patch to fix the recent security update. PostgreSQL gurus, would you consider applying this until a better solution is found for DBMirror.pl? Olivier, can you please confirm that the patch works for you, too? Thank you, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates? [ Attachment, skipping... ] -- End of PGP section, PGP failed! -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333854: [PATCHES] [BUGS] Bug#333854: pg_group file update problems
This bug will be fixed in the next 8.0.X release. I have not fixed
7.4.X because the risk/benefit does not warrant it, and 8.1 does not
have this problem.
---
Bruce Momjian wrote:
I have developed a small patch to 8.0.X that fixes your reported
problem:
test= CREATE GROUP g1;
CREATE GROUP
test= CREATE USER u1 IN GROUP g1;
CREATE USER
test= \! cat /u/pg/data/global/pg_group
g1u1
test= CREATE USER u2 IN GROUP g1;
CREATE USER
test= \! cat /u/pg/data/global/pg_group
g1u1 u2
test= ALTER USER u2 RENAME TO u3;
ALTER USER
test= \! cat /u/pg/data/global/pg_group
g1u1 u3
In the patch, notice the old comment that suggests we might need to use
CommandCounterIncrement().
This sesms safe to apply to back branches.
---
Dennis Vshivkov wrote:
Package: postgresql-8.0
Version: 8.0.3-13
Severity: important
Tags: patch, upstream
Here's the problem:
db=# CREATE GROUP g1;
CREATE GROUP
db=# CREATE USER u1 IN GROUP g1;(1)
CREATE USER
# cat /var/lib/postgresql/8.0/main/global/pg_group
#
The file gets rewritten, but the group `g1' line does not get
added to the file. Continue:
db=# CREATE USER u2 IN GROUP g1;(2)
CREATE USER
# cat /var/lib/postgresql/8.0/main/global/pg_group
g1u1
#
Now the line is there, but it lacks the latest member. Consider
this also:
db=# ALTER USER u2 RENAME TO u3;(3)
ALTER USER
# cat /var/lib/postgresql/8.0/main/global/pg_group
g1u1 u2
#
The problem is that the code that updates pg_group file resolves
group membership through the system user catalogue cache. The
file update happens shortly before the commit, but the caches
only see updates after the commit. Because of this, new users
or changes in users' names often do not make it to pg_group.
That leads to mysterious authentication failures subsequently.
The problem can also have security implications for certain
pg_hba.conf arrangements.
The attached `98-6-pg_group-stale-data-fix.patch' makes the code
in question access the system user table directly and thus fixes
the cases (1) and (2), however (3) is doubly ill: the user
renaming code does not even trigger a pg_group file update.
Hence the other patch, `98-5-rename-user-update-pg_group.patch'.
A byproduct of the main fix is removal of an unlikely system
cache reference leak which happens if a group member name
contains a newline.
The problems were found and the fixes were done for PostgreSQL
8.0.3 release. The flaws seem intact in 8.0.4 source code, too.
Hope this helps.
--
/Awesome Walrus [EMAIL PROTECTED]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/backend/commands/user.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/user.c,v
retrieving revision 1.147
diff -c -c -r1.147 user.c
*** src/backend/commands/user.c 31 Dec 2004 21:59:42 - 1.147
--- src/backend/commands/user.c 14 Oct 2005 15:42:17 -
***
*** 175,183
/*
* Read pg_group and write the file. Note we use SnapshotSelf to
! * ensure we see all effects of current transaction. (Perhaps could
! * do a CommandCounterIncrement beforehand, instead?)
*/
scan = heap_beginscan(grel, SnapshotSelf, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
--- 175,183
/*
* Read pg_group and write the file. Note we use SnapshotSelf to
! * ensure we see all effects of current transaction.
*/
+ CommandCounterIncrement();
scan = heap_beginscan(grel, SnapshotSelf, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
***
*** 781,786
--- 781,787
* Set flag to update flat password file at commit.
*/
user_file_update_needed();
+ group_file_update_needed();
}
***
*** 1200,1205
--- 1201,1207
* Set flag to update flat password file at commit.
*/
user_file_update_needed();
+ group_file_update_needed
Bug#333854: [BUGS] Bug#333854: pg_group file update problems
I can confirm your problem in current 8.0.X CVS. Your fixes to update pg_group when a user is added (because they might be added to a group at the same time) is correct too. And the visiblity problem is a valid bug too. --- Dennis Vshivkov wrote: Package: postgresql-8.0 Version: 8.0.3-13 Severity: important Tags: patch, upstream Here's the problem: db=# CREATE GROUP g1; CREATE GROUP db=# CREATE USER u1 IN GROUP g1;(1) CREATE USER # cat /var/lib/postgresql/8.0/main/global/pg_group # The file gets rewritten, but the group `g1' line does not get added to the file. Continue: db=# CREATE USER u2 IN GROUP g1;(2) CREATE USER # cat /var/lib/postgresql/8.0/main/global/pg_group g1u1 # Now the line is there, but it lacks the latest member. Consider this also: db=# ALTER USER u2 RENAME TO u3;(3) ALTER USER # cat /var/lib/postgresql/8.0/main/global/pg_group g1u1 u2 # The problem is that the code that updates pg_group file resolves group membership through the system user catalogue cache. The file update happens shortly before the commit, but the caches only see updates after the commit. Because of this, new users or changes in users' names often do not make it to pg_group. That leads to mysterious authentication failures subsequently. The problem can also have security implications for certain pg_hba.conf arrangements. The attached `98-6-pg_group-stale-data-fix.patch' makes the code in question access the system user table directly and thus fixes the cases (1) and (2), however (3) is doubly ill: the user renaming code does not even trigger a pg_group file update. Hence the other patch, `98-5-rename-user-update-pg_group.patch'. A byproduct of the main fix is removal of an unlikely system cache reference leak which happens if a group member name contains a newline. The problems were found and the fixes were done for PostgreSQL 8.0.3 release. The flaws seem intact in 8.0.4 source code, too. Hope this helps. -- /Awesome Walrus [EMAIL PROTECTED] [ Attachment, skipping... ] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333854: [BUGS] Bug#333854: pg_group file update problems
Tom Lane wrote: Dennis Vshivkov [EMAIL PROTECTED] writes: The problem is that the code that updates pg_group file resolves group membership through the system user catalogue cache. Good catch. The attached `98-6-pg_group-stale-data-fix.patch' makes the code in question access the system user table directly and thus fixes Wouldn't a CommandCounterIncrement be a much simpler solution? Since this code is all gone in CVS tip, there's not going to be any way of beta-testing a large patch ... and there's also not going to be a lot of support for pushing a large, poorly tested patch into the back branches. It is pretty clear where we are missing group_file_update_needed() in user.c. We did not anticipate the group being modified by CREATE USER, so adding the group_file_update_needed() seems trivial. If a CommandCounterIncrement() fixes the problem, that also seems like a trivial addition. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333854: [BUGS] Bug#333854: pg_group file update problems
I have developed a small patch to 8.0.X that fixes your reported
problem:
test= CREATE GROUP g1;
CREATE GROUP
test= CREATE USER u1 IN GROUP g1;
CREATE USER
test= \! cat /u/pg/data/global/pg_group
g1u1
test= CREATE USER u2 IN GROUP g1;
CREATE USER
test= \! cat /u/pg/data/global/pg_group
g1u1 u2
test= ALTER USER u2 RENAME TO u3;
ALTER USER
test= \! cat /u/pg/data/global/pg_group
g1u1 u3
In the patch, notice the old comment that suggests we might need to use
CommandCounterIncrement().
This sesms safe to apply to back branches.
---
Dennis Vshivkov wrote:
Package: postgresql-8.0
Version: 8.0.3-13
Severity: important
Tags: patch, upstream
Here's the problem:
db=# CREATE GROUP g1;
CREATE GROUP
db=# CREATE USER u1 IN GROUP g1;(1)
CREATE USER
# cat /var/lib/postgresql/8.0/main/global/pg_group
#
The file gets rewritten, but the group `g1' line does not get
added to the file. Continue:
db=# CREATE USER u2 IN GROUP g1;(2)
CREATE USER
# cat /var/lib/postgresql/8.0/main/global/pg_group
g1u1
#
Now the line is there, but it lacks the latest member. Consider
this also:
db=# ALTER USER u2 RENAME TO u3;(3)
ALTER USER
# cat /var/lib/postgresql/8.0/main/global/pg_group
g1u1 u2
#
The problem is that the code that updates pg_group file resolves
group membership through the system user catalogue cache. The
file update happens shortly before the commit, but the caches
only see updates after the commit. Because of this, new users
or changes in users' names often do not make it to pg_group.
That leads to mysterious authentication failures subsequently.
The problem can also have security implications for certain
pg_hba.conf arrangements.
The attached `98-6-pg_group-stale-data-fix.patch' makes the code
in question access the system user table directly and thus fixes
the cases (1) and (2), however (3) is doubly ill: the user
renaming code does not even trigger a pg_group file update.
Hence the other patch, `98-5-rename-user-update-pg_group.patch'.
A byproduct of the main fix is removal of an unlikely system
cache reference leak which happens if a group member name
contains a newline.
The problems were found and the fixes were done for PostgreSQL
8.0.3 release. The flaws seem intact in 8.0.4 source code, too.
Hope this helps.
--
/Awesome Walrus [EMAIL PROTECTED]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/backend/commands/user.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/user.c,v
retrieving revision 1.147
diff -c -c -r1.147 user.c
*** src/backend/commands/user.c 31 Dec 2004 21:59:42 - 1.147
--- src/backend/commands/user.c 14 Oct 2005 15:42:17 -
***
*** 175,183
/*
* Read pg_group and write the file. Note we use SnapshotSelf to
!* ensure we see all effects of current transaction. (Perhaps could
!* do a CommandCounterIncrement beforehand, instead?)
*/
scan = heap_beginscan(grel, SnapshotSelf, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
--- 175,183
/*
* Read pg_group and write the file. Note we use SnapshotSelf to
!* ensure we see all effects of current transaction.
*/
+ CommandCounterIncrement();
scan = heap_beginscan(grel, SnapshotSelf, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
***
*** 781,786
--- 781,787
* Set flag to update flat password file at commit.
*/
user_file_update_needed();
+ group_file_update_needed();
}
***
*** 1200,1205
--- 1201,1207
* Set flag to update flat password file at commit.
*/
user_file_update_needed();
+ group_file_update_needed();
}
***
*** 1286,1291
--- 1288,1294
heap_close(rel, NoLock);
user_file_update_needed();
+ group_file_update_needed();
}
Bug#333854: [PATCHES] [BUGS] Bug#333854: pg_group file update problems
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
In the patch, notice the old comment that suggests we might need to use
CommandCounterIncrement().
... which you failed to fix in any meaningful way. I'd suggest
/*
* Advance the commmand counter to ensure we see all results
* of current transaction.
*/
CommandCounterIncrement();
and then change SnapshotSelf to SnapshotNow, since there's no longer any
reason for it to be special. Compare to CVS tip which already does it
that way. See also the identical code in write_user_file (which perhaps
has no bug, but ISTM it should stay identical).
OK, updated patch.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/backend/commands/user.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/user.c,v
retrieving revision 1.147
diff -c -c -r1.147 user.c
*** src/backend/commands/user.c 31 Dec 2004 21:59:42 - 1.147
--- src/backend/commands/user.c 14 Oct 2005 17:36:54 -
***
*** 175,184
/*
* Read pg_group and write the file. Note we use SnapshotSelf to
!* ensure we see all effects of current transaction. (Perhaps could
!* do a CommandCounterIncrement beforehand, instead?)
*/
! scan = heap_beginscan(grel, SnapshotSelf, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
Datum datum,
--- 175,184
/*
* Read pg_group and write the file. Note we use SnapshotSelf to
!* ensure we see all effects of current transaction.
*/
! CommandCounterIncrement(); /* see our current changes */
! scan = heap_beginscan(grel, SnapshotNow, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
Datum datum,
***
*** 322,331
/*
* Read pg_shadow and write the file. Note we use SnapshotSelf to
!* ensure we see all effects of current transaction. (Perhaps could
!* do a CommandCounterIncrement beforehand, instead?)
*/
! scan = heap_beginscan(urel, SnapshotSelf, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
Datum datum;
--- 322,331
/*
* Read pg_shadow and write the file. Note we use SnapshotSelf to
!* ensure we see all effects of current transaction.
*/
! CommandCounterIncrement(); /* see our current changes */
! scan = heap_beginscan(urel, SnapshotNow, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
Datum datum;
***
*** 781,786
--- 781,787
* Set flag to update flat password file at commit.
*/
user_file_update_needed();
+ group_file_update_needed();
}
***
*** 1200,1205
--- 1201,1207
* Set flag to update flat password file at commit.
*/
user_file_update_needed();
+ group_file_update_needed();
}
***
*** 1286,1291
--- 1288,1294
heap_close(rel, NoLock);
user_file_update_needed();
+ group_file_update_needed();
}
Bug#333854: [PATCHES] [BUGS] Bug#333854: pg_group file update problems
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, updated patch.
I was sort of hoping that you would make the comments agree with the
code...
Oh, you really read those comments? Fixed and attached.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/backend/commands/user.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/user.c,v
retrieving revision 1.147
diff -c -c -r1.147 user.c
*** src/backend/commands/user.c 31 Dec 2004 21:59:42 - 1.147
--- src/backend/commands/user.c 14 Oct 2005 21:18:42 -
***
*** 174,184
errmsg(could not write to temporary file
\%s\: %m, tempname)));
/*
!* Read pg_group and write the file. Note we use SnapshotSelf to
!* ensure we see all effects of current transaction. (Perhaps could
!* do a CommandCounterIncrement beforehand, instead?)
*/
! scan = heap_beginscan(grel, SnapshotSelf, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
Datum datum,
--- 174,183
errmsg(could not write to temporary file
\%s\: %m, tempname)));
/*
!* Read pg_group and write the file
*/
! CommandCounterIncrement(); /* see our current changes */
! scan = heap_beginscan(grel, SnapshotNow, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
Datum datum,
***
*** 321,331
errmsg(could not write to temporary file
\%s\: %m, tempname)));
/*
!* Read pg_shadow and write the file. Note we use SnapshotSelf to
!* ensure we see all effects of current transaction. (Perhaps could
!* do a CommandCounterIncrement beforehand, instead?)
*/
! scan = heap_beginscan(urel, SnapshotSelf, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
Datum datum;
--- 320,329
errmsg(could not write to temporary file
\%s\: %m, tempname)));
/*
!* Read pg_shadow and write the file
*/
! CommandCounterIncrement(); /* see our current changes */
! scan = heap_beginscan(urel, SnapshotNow, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
Datum datum;
***
*** 781,786
--- 779,785
* Set flag to update flat password file at commit.
*/
user_file_update_needed();
+ group_file_update_needed();
}
***
*** 1200,1205
--- 1199,1205
* Set flag to update flat password file at commit.
*/
user_file_update_needed();
+ group_file_update_needed();
}
***
*** 1286,1291
--- 1286,1292
heap_close(rel, NoLock);
user_file_update_needed();
+ group_file_update_needed();
}
