Jeremy (and all),
just wanted to say that we moved (quicker than we wanted) to 3.0.x and
everything is fine!
Thanks so much !
Tom
On Wed, 19 Nov 2003, Jeremy Allison wrote:
On Wed, Nov 19, 2003 at 03:57:56PM -0500, Tom Ryan wrote:
yes.. but I was having problems before with that enabled
I've kept looking for an answer to this to no avail.. any ideas?
strace -p reveals
fcntl64(14, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=684, len=1},
0xb180) = 0
fcntl64(14, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=684, len=1},
0xb150) = 0
fcntl64(14, F_SETLKW64,
On Wed, Nov 19, 2003 at 03:14:02PM -0500, Tom Ryan wrote:
I've kept looking for an answer to this to no avail.. any ideas?
strace -p reveals
fcntl64(14, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=684, len=1},
0xb180) = 0
fcntl64(14, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET,
Jeremy,
(gdb) bt
#0 0x08173176 in tdb_brlock ()
#1 0x0817349a in tdb_unlock ()
#2 0x0817517a in tdb_next_lock ()
#3 0x081752a6 in tdb_traverse ()
#4 0x08179de4 in print_queue_status ()
#5 0x0807a6de in api_DosPrintQGetInfo ()
#6 0x0807fdd8 in api_reply ()
#7 0x08077e03 in reply_trans ()
On Wed, Nov 19, 2003 at 03:23:31PM -0500, Tom Ryan wrote:
Jeremy,
(gdb) bt
#0 0x08173176 in tdb_brlock ()
#1 0x0817349a in tdb_unlock ()
#2 0x0817517a in tdb_next_lock ()
#3 0x081752a6 in tdb_traverse ()
#4 0x08179de4 in print_queue_status ()
#5 0x0807a6de in api_DosPrintQGetInfo
2.2.7 on redhat 8. i uped lpq cache time = 60. doesn't seem to help.
Tom
On Wed, 19 Nov 2003, Jeremy Allison wrote:
On Wed, Nov 19, 2003 at 03:23:31PM -0500, Tom Ryan wrote:
Jeremy,
(gdb) bt
#0 0x08173176 in tdb_brlock ()
#1 0x0817349a in tdb_unlock ()
#2 0x0817517a in
On Wed, Nov 19, 2003 at 03:36:15PM -0500, Tom Ryan wrote:
2.2.7 on redhat 8. i uped lpq cache time = 60. doesn't seem to help.
How many print jobs do you have on this box ? Hmmm. As I recall,
a Win9x client with an open print monitor will just continually
scan the server - pounding it with
Jeremy,
All clients are windows xp.
Tom
On Wed, 19 Nov 2003, Jeremy Allison wrote:
On Wed, Nov 19, 2003 at 03:36:15PM -0500, Tom Ryan wrote:
2.2.7 on redhat 8. i uped lpq cache time = 60. doesn't seem to help.
How many print jobs do you have on this box ? Hmmm. As I recall,
a Win9x
On Wed, Nov 19, 2003 at 03:42:11PM -0500, Tom Ryan wrote:
Jeremy,
All clients are windows xp.
Ok, then you're not using the spoolss pipe code on the Samba
server, as this scanning behaviour goes away once WNT or above
clients can open the SPOOLSS pipe (they use a strange form of
change notify
yes.. but I was having problems before with that enabled previously.
On Wed, 19 Nov 2003, Jeremy Allison wrote:
On Wed, Nov 19, 2003 at 03:42:11PM -0500, Tom Ryan wrote:
Jeremy,
All clients are windows xp.
Ok, then you're not using the spoolss pipe code on the Samba
server, as this
I enabled that.. but I'm still having the same issue.
On Wed, 19 Nov 2003, Tom Ryan wrote:
yes.. but I was having problems before with that enabled previously.
On Wed, 19 Nov 2003, Jeremy Allison wrote:
On Wed, Nov 19, 2003 at 03:42:11PM -0500, Tom Ryan wrote:
Jeremy,
All
On Wed, Nov 19, 2003 at 03:57:56PM -0500, Tom Ryan wrote:
yes.. but I was having problems before with that enabled previously.
The client behaviour changes once spoolss is enabled. If you're
claiming to see the same issue on the clients you need to restart
the spooler service on them in order
We are in the middle of planning our upgrade.
Thanks will try this and report back!
Tom
On Wed, 19 Nov 2003, Jeremy Allison wrote:
On Wed, Nov 19, 2003 at 03:57:56PM -0500, Tom Ryan wrote:
yes.. but I was having problems before with that enabled previously.
The client behaviour changes
Does anyone have any thoughts on this? Any things that I can try? I'm open
to suggestions :)
Tom
On Thu, 9 Oct 2003, Tom Ryan wrote:
Ok.. still researching this. should i try disabling kernel oplocks? also,
any thoughts on why it only happens to certain user processes?
could it be a
Looking around on the net, I saw that someone else had a similar issue
when they were running all of their users behind terminal server. Our
users are all behind two NAT'd firewalls.
Is it possible that there is some confusion going on? should I stop the
service and remove locking.tdb? (that's
Jeremy,
2.4.20-19.8 on redhat 8
strace reports
fcntl64(14, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=628, len=1},
0xb150) = 0
fcntl64(14, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=632, len=1},
0xb150) = 0
over and over again (with different start points)
Tom
On Wed,
16 matches
Mail list logo
