Your message dated Sat, 9 Jun 2012 16:17:16 +0200
with message-id <[email protected]>
and subject line Re: Bug#520744: _SC_GETGR_R_SIZE_MAXÂ returned on amd64 too
small
has caused the Debian Bug report #520744,
regarding getgrnam_r(3): wrong explanation about the
sysconf(_SC_GETGR_R_SIZE_MAX) value
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
520744: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520744
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libvirt-bin
Version: 0.6.1-1
Severity: normal
Hi,
On some machines (at least reproduceable on them) when I installed
libvirt I get the following error when libvirt gets started:
unki@srv-mfm-vm02:~$ grep libvirt /var/log/syslog
Mar 22 14:56:31 srv-mfm-vm02 libvirtd: 14:56:31.347: error : Failed to lookup
group 'libvirt'
unki@srv-mfm-vm02:~$
But that is not the case on all machines. On some of them libvirt
immediatley works after installation. But on the others - the
group 'libvirt' is there:
unki@srv-mfm-vm02:~$ grep libvirt /etc/group
libvirt:x:113:
Also the directory containing the socket files is correctly owned:
unki@srv-mfm-vm02:~$ ls -ld /var/run/libvirt
drwxr-xr-x 3 root libvirt 58 2009-03-22 14:40 /var/run/libvirt
If I change unix_sock_group in libvirtd.conf for example to "root",
libvirtd is willing to start.
It also make no difference, if group 'libvirt' has members or not.
Cheers,
Andreas
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libvirt-bin depends on:
ii adduser 3.110 add and remove users and groups
ii libavahi-client3 0.6.23-3lenny1 Avahi client library
ii libavahi-common3 0.6.23-3lenny1 Avahi common library
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libdbus-1-3 1.2.1-5 simple interprocess messaging syst
ii libgcrypt11 1.4.1-1 LGPL Crypto library - runtime libr
ii libgnutls26 2.4.2-6+lenny1 the GNU TLS library - runtime libr
ii libgpg-error0 1.4-2 library for common error values an
ii libhal1 0.5.11-8 Hardware Abstraction Layer - share
ii libpolkit-dbus2 0.9-2 library for accessing PolicyKit vi
ii libpolkit2 0.9-2 library for accessing PolicyKit
ii libreadline5 5.2-3.1 GNU readline and history libraries
ii libsasl2-2 2.1.22.dfsg1-23 Cyrus SASL - authentication abstra
ii libselinux1 2.0.65-5 SELinux shared libraries
ii libtasn1-3 1.4-1 Manage ASN.1 structures (runtime)
ii libvirt0 0.6.1-2~mm.1 library for interfacing with diffe
ii libxenstore3.0 3.2.1-2 Xenstore communications library fo
ii libxml2 2.6.32.dfsg-5 GNOME XML library
ii logrotate 3.7.1-5 Log rotation utility
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages libvirt-bin recommends:
ii bridge-utils 1.4-5 Utilities for configuring the Linu
pn dnsmasq-base <none> (no description available)
ii iptables 1.4.2-6 administration tools for packet fi
ii netcat-openbsd 1.89-3 TCP/IP swiss army knife
ii qemu 0.9.1-10 fast processor emulator
Versions of packages libvirt-bin suggests:
pn policykit <none> (no description available)
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 3.40-0.1
Hello,
On Fri, Apr 24, 2009 at 03:38:19PM +0200, Aurelien Jarno wrote:
> reassign 520744 manpages-dev
> retitle 520744 getgrnam_r(3): wrong explanation about the
> sysconf(_SC_GETGR_R_SIZE_MAX) value
> thanks
>
> On Fri, Apr 24, 2009 at 12:43:07PM +0200, Guido Günther wrote:
> > On Fri, Apr 24, 2009 at 12:27:49PM +0200, Aurelien Jarno wrote:
> > [..snip..]
> > > That said I don't fully understand POSIX here. What should happen if a
> > > line in /etc/group needs more memory than sysconf(_SC_GETGR_R_SIZE_MAX)?
> > > The line should be truncated? As far as I understand user can create as
> > > many entries as he wants there, so _SC_GETGR_R_SIZE_MAX can only be
> > > defined to an arbitrary value.
> > The manpage (as well as posix) says:
> >
> > The maximum needed size for buf can be found using sysconf(3) with the
> > argument _SC_GETGR_R_SIZE_MAX.
> >
> > I don't understand how this is supposed to work with arbitrary large
> > groups given that gr_mem is part of the buffer. It's probaly just a
> > documentation bug that should read "minimum" instead of "maximum"?
>
> Actually the latest POSIX documentation (IEEE Std 1003.1-2008) changed
> this part, and now says:
>
> | A call to sysconf(_SC_GETGR_R_SIZE_MAX) returns either -1 without
> | changing errno or an initial value suggested for the size of this
> | buffer.
Fixed upstream, available in debian manpages-dev 3.40-0.1:
http://git.kernel.org/?p=docs/man-pages/man-pages.git;a=commitdiff;h=f7bae7f86
The call
sysconf(_SC_GETGR_R_SIZE_MAX)
returns either -1, without changing errno, or an initial suggested size for
buf. (If this size is too small, the call fails with ERANGE, in which case the
caller can retry with a larger buffer.)
--
Simon Paillard
--- End Message ---
