From: Jeff Yana <jyana@(email surpressed)>
Subject: ERROR: can't create log: //FILE/path/name: No such file or directory
   Date: Thu, 06 Jan 2005 16:08:35 -0800

The problem:

ERROR: can't create log: //FILE/path/name: No such file or directory

I have seen this problem in the following situations:

Does anybody have any ideas why this might be happening?

Thanks.

Jeff

Jeff Yana wrote:

The problem:

A single WinXP workstation in an environment of 10+ XP machines cannot render. The Job submits successfully, but almost immediately fails, generating the following error:

ERROR: can't create log: //FILE/path/name: No such file or directory

	If you manually login to this machine as the user the Rushd
	service is running as, and try to create a file in that directory,
	do you get similar errors? eg:

		dir \\FILE\path\name
		echo foo > \\file\path\name\test.txt

> A single WinXP workstation in an environment of 10+ XP machines cannot render.

	A few things come to mind:

		o Verify the Rushd service is running as a user that has access
		  to the file server. eg. a valid account similar to the other
		  machines, and not using the 'System' account.

		o Make sure it isn't a file server issue, eg. a
		  Windows file server that ran out of Microsoft CAL licenses.

	Sure sounds like one of the above.

	I imagine you should be able to replicate the problem from DOS
	assuming you login as the user the Rushd service is configured
	to run as.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

Greg Ercolano wrote:

Jeff Yana wrote:

The problem:

A single WinXP workstation in an environment of 10+ XP machines cannot render. The Job submits successfully, but almost immediately fails, generating the following error:

ERROR: can't create log: //FILE/path/name: No such file or directory

    If you manually login to this machine as the user the Rushd
    service is running as, and try to create a file in that directory,
    do you get similar errors? eg:

        dir \\FILE\path\name
        echo foo > \\file\path\name\test.txt

> A single WinXP workstation in an environment of 10+ XP machines cannot render.

    A few things come to mind:

        o Verify the Rushd service is running as a user that has access
          to the file server. eg. a valid account similar to the other
          machines, and not using the 'System' account.

        o Make sure it isn't a file server issue, eg. a
          Windows file server that ran out of Microsoft CAL licenses.

    Sure sounds like one of the above.

    I imagine you should be able to replicate the problem from DOS
    assuming you login as the user the Rushd service is configured
    to run as.

Jeff Yana wrote:

Not sure what cleared this problem up but my suspicion is that the artist has assigned an incorrect path to the imagedir. Why this caused the cannot create log file error is beyond me. Any thoughts anyone?

	Sounds like shadowy file server stuff.. possibly old data being
	cached on this one machine, either an old scene file, or a bad
	cached interpretation of the directory.

	This might put suspicion on the file server's configuration of
	opportunistic locking.

	I've seen eg. Samba servers have trouble with op locks, for instance
	on my own network I have oplocks turned off to prevent clients caching
	incorrectly:

--- snip: smb.conf excerpt

# DISABLE OPLOCKS TO ALLOW UNIX AND NT TO ALTER SERVER DATA
#    If no: clients won't cache, but will stay in sync
#    If yes: clients cache, but out of sync with unix
#
oplocks = no

--- snip

	Without that setting, my windows machines would often not see
	changes made to files from other machines. I've seen this at
	other companies too; disabling oplocks usually fixes it.

	If it happens again, troubleshoot from the DOS prompt directly
	at the machine having the problem. Do it quickly, since if it
	is a caching problem, it may mysteriously 'solve itself' when
	the cache expires.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

Greg Ercolano wrote:

Jeff Yana wrote:

Not sure what cleared this problem up but my suspicion is that the artist has assigned an incorrect path to the imagedir. Why this caused the cannot create log file error is beyond me. Any thoughts anyone?

    Sounds like shadowy file server stuff.. possibly old data being
    cached on this one machine, either an old scene file, or a bad
    cached interpretation of the directory.

    This might put suspicion on the file server's configuration of
    opportunistic locking.

    I've seen eg. Samba servers have trouble with op locks, for instance
    on my own network I have oplocks turned off to prevent clients caching
    incorrectly:

--- snip: smb.conf excerpt

# DISABLE OPLOCKS TO ALLOW UNIX AND NT TO ALTER SERVER DATA
#    If no: clients won't cache, but will stay in sync
#    If yes: clients cache, but out of sync with unix
#
oplocks = no

--- snip

    Without that setting, my windows machines would often not see
    changes made to files from other machines. I've seen this at
    other companies too; disabling oplocks usually fixes it.

    If it happens again, troubleshoot from the DOS prompt directly
    at the machine having the problem. Do it quickly, since if it
    is a caching problem, it may mysteriously 'solve itself' when
    the cache expires.

Greg-

Good suggestion, thanks.

Jeff

Jeff Yana wrote:

[posted to rush.general]

    Sounds like shadowy file server stuff.. possibly old data being
    cached on this one machine, either an old scene file, or a bad
    cached interpretation of the directory.

    This might put suspicion on the file server's configuration of
    opportunistic locking.
[..]
oplocks = no
[..]

I think your suspicions are correct. Many artists accessing our Linux Server have had trouble with file systems/path names not updating in the RUSH submit dialog, leading to much confusion (and misdirected blame) vis a vis RUSH.

	Yeah, Rush in particular brings file system synchronization problems
	to light quickly, because it pulls many machines into action all at once.

	A common scenario; a user tweaks their maya scene file, saves, then
	requeues the frames in their job, and 100 machines starts accessing
	that file, all within a few seconds.

	Even a small hiccup in file caching will become obvious instantly.

	Or worse, if the artist doesn't have a healthy suspicion of computers,
	they will be chasing the shadows, assuming the fault is their own;
	"I just fixed that!", and will try changing other things. Then suddenly,
	for no apparent reason at all, it all suddenly starts working when the
	caches expire.

	It's stuff like this that frazzles artists if it happens enough..
	their hands visibly shaking at the coffee machine..

	I guess this is where an investment in an expensive NetApp file server
	comes back as a savings to everyone's sanity.

There has even been a whole host of problems getting Windows explorer on some machines to accurately refresh, or not refresh at all.

	By 'explorer', I imagine you mean the folder browsers in Windows; yes.

	They are automatically supposed to update when the file server tells
	them files have been changed or added.

	Example: if a linux client creates a new directory on the file server,
	the file server's /kernel/ is supposed to notify samba, and /samba/
	is supposed to notify any clients that are 'watching' that directory tree,
	(eg. window's 'explorer' browser) so that they update their on-screen
	directory listings automatically. (Otherwise you have to hit F4 to poll it)

	If you have a commercial file server, beat on their support, because
	they should have configured all this for you with defaults consistent
	with Microsoft's own, as that's what you're paying for.

	If you have a custom file server /you/ set up, then look closely at
	the samba docs on this stuff;

		For file caching, see the 'OPLOCKS' sections (level 1 and 2)
		in Speed.txt (as well as other sections in that doc, eg. the
		TCP_NODELAY socket option) and the smb.conf(5) man page.

		For folder browsers not updating, see 'notify timeout'
		in smb.conf(5), and related flags. For kernel related docs
		on directory notification (which I *think* is what samba must use),
		see /usr/src/linux/Documentation/dnotify.txt.

	For complete information saturation, see the Samba mailing list archives.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

Greg Ercolano wrote:

Jeff Yana wrote:

[posted to rush.general]

    Sounds like shadowy file server stuff.. possibly old data being
    cached on this one machine, either an old scene file, or a bad
    cached interpretation of the directory.

    This might put suspicion on the file server's configuration of
    opportunistic locking.
[..]
oplocks = no
[..]

I think your suspicions are correct. Many artists accessing our Linux Server have had trouble with file systems/path names not updating in the RUSH submit dialog, leading to much confusion (and misdirected blame) vis a vis RUSH.

    Yeah, Rush in particular brings file system synchronization problems

to light quickly, because it pulls many machines into action all at once.

    A common scenario; a user tweaks their maya scene file, saves, then
    requeues the frames in their job, and 100 machines starts accessing
    that file, all within a few seconds.

    Even a small hiccup in file caching will become obvious instantly.

    Or worse, if the artist doesn't have a healthy suspicion of computers,
    they will be chasing the shadows, assuming the fault is their own;

"I just fixed that!", and will try changing other things. Then suddenly,

    for no apparent reason at all, it all suddenly starts working when the
    caches expire.

    It's stuff like this that frazzles artists if it happens enough..
    their hands visibly shaking at the coffee machine..

    I guess this is where an investment in an expensive NetApp file server
    comes back as a savings to everyone's sanity.

There has even been a whole host of problems getting Windows explorer on some machines to accurately refresh, or not refresh at all.

    By 'explorer', I imagine you mean the folder browsers in Windows; yes.

    They are automatically supposed to update when the file server tells
    them files have been changed or added.

    Example: if a linux client creates a new directory on the file server,
    the file server's /kernel/ is supposed to notify samba, and /samba/

is supposed to notify any clients that are 'watching' that directory tree,

    (eg. window's 'explorer' browser) so that they update their on-screen

directory listings automatically. (Otherwise you have to hit F4 to poll it)

    If you have a commercial file server, beat on their support, because
    they should have configured all this for you with defaults consistent
    with Microsoft's own, as that's what you're paying for.

Cheers!

    If you have a custom file server /you/ set up, then look closely at
    the samba docs on this stuff;

        For file caching, see the 'OPLOCKS' sections (level 1 and 2)
        in Speed.txt (as well as other sections in that doc, eg. the
        TCP_NODELAY socket option) and the smb.conf(5) man page.

        For folder browsers not updating, see 'notify timeout'
        in smb.conf(5), and related flags. For kernel related docs
        on directory notification (which I *think* is what samba must use),
        see /usr/src/linux/Documentation/dnotify.txt.

For complete information saturation, see the Samba mailing list archives.