Network start-up in freewrap
MSEdit
I have recompiled the last BLT version of freewrap (with tcl 8.4.19)
on RHEL5 and have a few problems at start-up.
At first I thought it was my application, but just using freewish
causes a problem.
On the same machine our wish (also 8.4.19) has no problems
After using wireshark my colleagues found that a DNS request on a
pkgIndex.tcl URL is being sent, and a time-out follows causing up to a
few minutes startup.
gdb shows that the function NativeMatchType is current.
It appears that fts_open is being used to access a file pkgIndex.tcl
in all the sub directories of /. The problem arises on the /net
directory with the autofs service activated but with no DNS valid.
If there is no active DNS then accessing /net/pkgIndex.tcl will cause
a DNS timeout. On top of that this access seems to be in a loop and is
activated several times, causing even longer startups.
Initially we replied that this was a problem with the network set-up
but the customer replied that as this is the only application causing
a problem so it is obviously a problem with the application.
Does anyone have any ideas about this problem or at least what we can
look at to investigate further.
Thanks in advance
Martyn
Donald G Porter
> It appears that fts_open is being used to access a file pkgIndex.tcl
> in all the sub directories of /.
> Does anyone have any ideas about this problem or at least what we can
> look at to investigate further.
The search for pkgIndex.tcl files is govered by the value of the
$::auto_path variable. What value does it have in the misbehaving
application? If, as the symptoms suggest, the filesystem path "/"
has been placed in the list, then determine why, and stop that.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
MSEdit
> MSEdit wrote:
> > It appears that fts_open is being used to access a file pkgIndex.tcl
> > in all the sub directories of /.
> ...
> > Does anyone have any ideas about this problem or at least what we can
> > look at to investigate further.
>
> The search for pkgIndex.tcl files is govered by the value of the
> $::auto_path variable. What value does it have in the misbehaving
> application? If, as the symptoms suggest, the filesystem path "/"
> has been placed in the list, then determine why, and stop that.
>
> --
> | Don Porter Mathematical and Computational Sciences Division |
> |http://math.nist.gov/~DPorter/ NIST |
> |______________________________________________________________________|
This action happens before My application code is accessed I have not
modified the auto_path. Maybe freewrap has an extended auto_path for
internal stuff.
Renaming freewrap as freewish causes it to work as a wish and it has
the same problem.
Is the auto_path the only access within TCL to the pkgIndex.tcl files
or is there some internal Cleve access ?
Martyn
DTM
> MSEdit wrote:
> > It appears that fts_open is being used to access a file pkgIndex.tcl
> > in all the sub directories of /.
> ...
> > Does anyone have any ideas about this problem or at least what we can
> > look at to investigate further.
>
> The search for pkgIndex.tcl files is govered by the value of the
> $::auto_path variable. What value does it have in the misbehaving
> application? If, as the symptoms suggest, the filesystem path "/"
> has been placed in the list, then determine why, and stop that.
FreeWrap does not add "/" as part of the auto_path variable. It
internally mounts the TCL and TK library directories at /tcl and /tk
respectively.
I have seen slow start up times on some systems which have
particularly slow I/O response times (e.g., from slow networks or some
anti-virus programs). This slow down is not necessarily linear. There
seems to be some threshold of I/O response time above which the number
of I/O retries quickly becomes enormous and it will take a couple of
minutes for the freeWrap application to start.
On the affected systems I have had the most success improving
performance by replacing the anti-virus application with one that
provides a "quicker" response to I/O requests. Improving the network
connection has also helped.
If there is some other cause or solution I would really like to hear
about it so I could try to fix the problem within freeWrap itself.
Dennis LaBelle (freeWrap author)
Alexandre Ferrieux
Well, something inside freeWrap is still insisting on finding /*/
pkgIndex.tcl, as witnessed by the following strace excerpt from
version 6.42 on a Fedora 12. On my system it is okay, but if I had a /
net with kind auto_host, what the OP mentions would have struck me
too, with the automount daemon trying to resolve a host named pkgIndex
in domain tcl...
-Alex
open("/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
fcntl64(4, F_GETFD) = 0x1 (flags FD_CLOEXEC)
getdents(4, /* 25 entries */, 32768) = 436
stat64("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
stat64("/selinux", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/sbin", {st_mode=S_IFDIR|0555, st_size=12288, ...}) = 0
stat64("/lib", {st_mode=S_IFDIR|0555, st_size=12288, ...}) = 0
stat64("/mnt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/root", {st_mode=S_IFDIR|0550, st_size=4096, ...}) = 0
stat64("/bin", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
stat64("/srv", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/media", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/dev", {st_mode=S_IFDIR|0755, st_size=4080, ...}) = 0
stat64("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/boot", {st_mode=S_IFDIR|0555, st_size=1024, ...}) = 0
stat64("/xp", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
stat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/opt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/etc", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
stat64("/lost+found", {st_mode=S_IFDIR|0700, st_size=16384, ...}) = 0
stat64("/sys", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents(4, /* 0 entries */, 32768) = 0
close(4) = 0
...
lstat64("/proc/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/selinux/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file
or directory)
lstat64("/sbin/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/lib/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/mnt/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/root/pkgIndex.tcl", 0xbf996d0c) = -1 EACCES (Permission
denied)
lstat64("/bin/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/srv/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/media/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file
or directory)
lstat64("/var/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/dev/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/home/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/boot/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/xp/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/tmp/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/usr/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/opt/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/etc/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
lstat64("/lost+found/pkgIndex.tcl", 0xbf996d0c) = -1 EACCES
(Permission denied)
lstat64("/sys/pkgIndex.tcl", 0xbf996d0c) = -1 ENOENT (No such file or
directory)
MSEdit
wrote:
This is more or less the same output we get from strace except we have
a /net directory and the strace output blocks at /net/pkgIndex.tcl
until the DNS times out then everything restarts.
Dennis, I found a comment in one of the headers that you no longer add
'/' to the auto_path, but something seems to still be scanning the /
directory.
After startup a puts of $auto_path does not have any reference to /.
/tcl/msgcat1.3
/tcl/http2.5
/tcl/tcltest2.2
/tcl/http1.0
/tcl/opt0.4
/tcl/encoding
/tcl
/tcl
/tk
/blt
/users/xxx/....../Myapp
Martyn
Don Porter
> After startup a puts of $auto_path does not have any reference to /.
After startup, does a [package require] of an unknown package
exhibit the same problem?