Re: 5.0 linux emul problem?

[christos%astron.com@localhost (Christos Zoulas)]

In article <20110222150001.GC16582%kyyhky.embedtronics.fi@localhost>,
Jukka Marin  <jmarin%embedtronics.fi@localhost> wrote:
>Hello List,
>
>I updated a linux license server on my NetBSD 5.0 system and now it won't
>run any more.  The license server thinks there's another copy running (which
>is not true).  Here's a kdump output of the process just before it decides
>to exit:
>
> 21345      1 mgcld    CALL  access(0x811d0a9,6)
> 21345      1 mgcld    NAMI  "/emul/linux/usr/tmp/.flexlm"
> 21345      1 mgcld    NAMI  "/usr/tmp/.flexlm"
> 21345      1 mgcld    RET   access 0
> 21345      1 mgcld    CALL  lstat64(0x811d0a9,0xbb3f958c)
> 21345      1 mgcld    NAMI  "/emul/linux/usr/tmp/.flexlm"
> 21345      1 mgcld    NAMI  "/usr/tmp/.flexlm"
> 21345      1 mgcld    RET   lstat64 0
> 21345      1 mgcld    CALL  open(0x8191720,2,0)
> 21345      1 mgcld    NAMI  "/emul/linux/var/tmp/lockmgcld"
> 21345      1 mgcld    NAMI  "/var/tmp/lockmgcld"
> 21345      1 mgcld    RET   open 4
> 21345      1 mgcld    CALL  fcntl64(4,6,0xbb3f968c)
> 21345      1 mgcld    RET   fcntl64 -1 unknown errno 35
> 21345      1 mgcld    CALL  time(0)
> 21345      1 mgcld    RET   time 1298384794/0x4d63c79a
> 21345      1 mgcld    CALL  write(1,0xbb66e000,0x30)
> 21345      1 mgcld    GIO   fd 1 wrote 48 bytes
>       "16:26:34 (mgcld) lost lock, exiting (errno: 11)\n"
> 21345      1 mgcld    RET   write 48/0x30
> 21345      1 mgcld    CALL  time(0)
> 21345      1 mgcld    RET   time 1298384794/0x4d63c79a
> 21345      1 mgcld    CALL  time(0)
> 21345      1 mgcld    RET   time 1298384794/0x4d63c79a
> 21345      1 mgcld    CALL  write(1,0xbb66e000,0x38)
> 21345      1 mgcld    GIO   fd 1 wrote 56 bytes
>       "16:26:34 (mgcld) EXITING DUE TO SIGNAL 41 Exit reason 9\n"
>
>Are there known bugs in fcntl64 emulation?  The file exists and is
>empty (owned by the user running mgcld).  I don't really want to set up a
>linux machine just to run this one license server binary... :-I

Sorry for asking the obvious, but when you remove it, does the process
re-create it? You could add some debugging, but it seems to me that as
you said the SETLK call thinks it is already locked.

christos