Hello,
I've installed a test machine and everything looks good so far. Thank
you all who were involved in fixing this bug.
Regards
hmw
Here is the upstream master branch commit to work around this libc bug:
https://github.com/krb5/krb5/commit/65110210b75d38908cdd84cb202cf013ccf6ed0e
It will make its way onto the 1.14 branch and into a future 1.14 patch
release.
>From what I can tell, _LARGEFILE_SOURCE only seems to provide prototypes
for fseeko() and ftello(). I assume Sam means building such that off_t
is 64 bits, which I think requires defining _FILE_OFFSET_BITS=64.
off_t doesn't appear in any public krb5 header file, so there shouldn't
be any direct
For debian, is there any reason not to build krb5 with
_LARGEFILE_SOURCE?
This appears to be gnu libc bug 20251, which does not appear to have
been fixed yet:
https://sourceware.org/bugzilla/show_bug.cgi?id=20251
We will explore workarounds. I have opened a ticket in our database to
track the issue:
http://krbdev.mit.edu/rt/Ticket/Display.html?id=8474
On Thu, 11 Aug 2016, Greg Hudson wrote:
> I do not understand the kernel behavior reflected in this trace
> output. For fd 3 (principal.ok), we see:
Yes, it would be good to get the kernel version from the reporter on the
affected machine (and the unaffected ones, too, for comparison).
(Using
control: retitle -1 kdb5_util hangs forever on 32-bit systems
--Sam
Hello,
I just installed five test machines with the 64 bit variant of Debian
and all of them seem to work as expected. The trace looks a bit
different:
open("/var/lib/krb5kdc/principal.ok", O_RDWR|O_CREAT|O_TRUNC, 0600) = 3
fcntl(3, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
Hello,
Sam Hartman wrote:
>
> So, in particular, it looks like kdb5_util is acquiring a lock from 0 to
> bignum that fails, acquiring a lock from 0 to 0 that succeeds, releasing
> the lock from 0 to bignum (which succeeds?), and then while still
> holding the lock from 0 to 0 tries to get
Hello,
Benjamin Kaduk wrote:
[...]
> It's probably worth noting that I think this is the first set of krb5
> packages built using gcc6; there may be some complications as a result of
> that.
>
> Or it may just be a more mundane bug relating to OFD locks,
I made another observation, which I
So, in particular, it looks like kdb5_util is acquiring a lock from 0 to
bignum that fails, acquiring a lock from 0 to 0 that succeeds, releasing
the lock from 0 to bignum (which succeeds?), and then while still
holding the lock from 0 to 0 tries to get another lock from 0 to bignum.
At least
I do not understand the kernel behavior reflected in this trace
output. For fd 3 (principal.ok), we see:
fcntl64(3, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
l_len=6950411022381350912}) = -1 EINVAL (Invalid argument)
fcntl64(3, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET,
severity 834035 serious
thanks
On Thu, 11 Aug 2016, Michael Welle wrote:
> Package: krb5-kdc
> Version: 1.14.3+dfsg-1
> Severity: critical
I do not see why critical severity is justified based on the supplied
information. I am willing to declare that this behavior makes the package
unfit for
Package: krb5-kdc
Version: 1.14.3+dfsg-1
Severity: critical
Hello,
I try create a database with the command
kdb5_util create -s -P foo
That seems to hang forever. Relevant part of a trace:
open("/var/lib/krb5kdc/principal.ok", O_RDWR|O_CREAT|O_TRUNC, 0600) = 3
fcntl64(3, F_OFD_SETLKW,
14 matches
Mail list logo
