backtrace when it hangs?
this sounds familiar
Derrick
On Wed, 16 Aug 2006, seth vidal wrote:
Hi,
We're testing out the audit log functionality of vol servers on openafs
1.4.0 on centos 4 x86_64 boxes. Right now if we add -auditlog to the
startup of the volserver then we get a deadlock after th
Hi,
We're testing out the audit log functionality of vol servers on openafs
1.4.0 on centos 4 x86_64 boxes. Right now if we add -auditlog to the
startup of the volserver then we get a deadlock after the first couple
of transactions.
I've looked through openafs 1.4.1 and diffed it versus 1.4.0 and
Ken Hornstein <[EMAIL PROTECTED]> writes:
> AFAIK, Ubik's concept is a "shared disk file"; at the level replication
> is handled, it has no idea what the underlying database format is.
> So while I also prefer to have Ubik copy it over, just using cp or
> whatever should be fine (all of the AFS dat
Russ Allbery wrote:
Rather than disabling pam_afs session handling entirely, you probably just
want to put "no_unlog" on the option line for the session invocation of
that module.
Thanks! That works just fine.
---Bob.
___
OpenAFS-info maili
On Wednesday, August 16, 2006 03:28:54 PM -0400 Ken Hornstein
<[EMAIL PROTECTED]> wrote:
I don't know of any reason why this wouldn't work, but I have to admit
that I'm really partial to transferring the database over protocol rather
than making the new server read the old disk file format.
>I don't know of any reason why this wouldn't work, but I have to admit
>that I'm really partial to transferring the database over protocol rather
>than making the new server read the old disk file format. I know that if
>you bring up a new server and let Ubik handle the replication, you don't
>ha
Joe,
I chose your #2 method of moving my DB servers (4), over the course of a few
weeks during the summer of 04. I believe both methods has merits and I'll
wager you won't have trouble in any case.
The only caveat with method #1 is if you've made some mistake in the
configuration of one DB serve
Joe Di Lellio <[EMAIL PROTECTED]> writes:
> 1) Bring all the old servers down. Copy over DB & others files to new
> systems. Swap in the new systems IP/hostname wise & bring them back up.
> This approach is what John Harris et al suggested, and looks to be
> pretty quick (he estimated 20 minute
Bob Hoffman <[EMAIL PROTECTED]> writes:
> That was it. I'm using the pam_afs.so module that came in
> openafs-client-1.4.1-rhel4.2.i386.rpm.
> In my /etc/pam.d/system_auth file, I had a "session" entry that called
> pam_afs.so. Commenting
> that out allows the token to remain. Now all I have to
Derrick,
Groups says:
arsenic:1 % groups
wheel id: cannot find name for group ID 34382
34382 id: cannot find name for group ID 40752
40752 root root bin sys tty mem mail news floppy utmp colorps okadmin
mailman gradapp gradappcs
arsenic:2 % su
Password:
Setting erase to ^?
arsenic:1 # groups
r
First of all, thanks to all who've responded, especially John Harris,
Brian Sebby and Jeffrey Hutzelman.
It looks like mixing the TransArc & OpenAFS fileservers isn't going to
be an issue - good, as less trouble is always nice. I'll just bring the
new systems into the mix and vos move stuff over
On Wednesday, August 16, 2006 01:49:04 PM -0400 Bob Hoffman
<[EMAIL PROTECTED]> wrote:
Found system call table at 0xc03219bc (pattern scan)
This line indicates it did indeed find the system call table.
In which case, I'm going to guess that Russ's diagnosis is probably the
right one.
Jeffrey Hutzelman wrote:
I suspect that if you run dmesg immediately after loading the AFS
kernel module, you'll find that it was unable to find and patch the
system call table. That means it's not intercepting calls to
setgroups(), and you end up losing your PAG at inconvenient times.
Than
Bob Hoffman <[EMAIL PROTECTED]> writes:
> I'm having the following problem on our Red Hat Enterprise 4 systems
> using the 2.6 kernel -- after exiting from a 'su' session, my token is
> gone. This did not occur under the 2.4 kernel.
> 2. Red Hat Enterprise 4. The token acquired at login is ret
Failure to hook setgroups on the 2.6 machine? What does "groups" say
before and after su?
On Wed, 16 Aug 2006, Bob Hoffman wrote:
I'm having the following problem on our Red Hat Enterprise 4 systems using
the 2.6 kernel --
after exiting from a 'su' session, my token is gone. This did not occu
On Wednesday, August 16, 2006 12:35:39 PM -0400 Bob Hoffman
<[EMAIL PROTECTED]> wrote:
I'm having the following problem on our Red Hat Enterprise 4 systems
using the 2.6 kernel --
after exiting from a 'su' session, my token is gone. This did not occur
under the 2.4 kernel.
I suspect that
I'm having the following problem on our Red Hat Enterprise 4 systems
using the 2.6 kernel --
after exiting from a 'su' session, my token is gone. This did not occur
under the 2.4 kernel.
Some examples:
1. Red Hat Enterprise 3 -- the token acquired at login is retained
through the su session
David, Agreed.
On 8/15/06, David Werner <[EMAIL PROTECTED]> wrote:
Dear List,
Now it seems that NFSv4 seems to be included in the standard linux-kernel and
the larger distributors turn it on or even apply their own patches
to keep it current.
I cant say much about the quality of their current s
18 matches
Mail list logo
