Acu Cobol 6.0 for Linux
Dan Nelson
dnelson at allantgroup.com
Tue Feb 3 11:20:36 PST 2004
In the last episode (Feb 03), Walter C. Pelissero said:
> I tried linux_kdump (from ports) and things seem to clarify a bit.
>
> I concentrated on acushare, which is the daemon that supervises
> inter-process locking (locking on file access) and licence
> verification. Whereas acushare seems to start properly, an attempt to
> kill it through the recommended means (not with kill(1)), yields an
> IPC error. On Linux strace on the daemon process shows:
>
> msgrcv(256, {1, "\254\1\0\0\6\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...}, 100, 1, MSG_NOERROR) = 12
> getpid() = 376
> getuid32() = -1 ENOSYS (Function not implemented)
> msgctl(256, IPC_STAT, 0xbffffa54) = 0
> msgsnd(256, {428, "x\1\0\0\6\0\0\0\6\0\0\0"}, 12, 0) = 0
>
> That is, msgrcv returns a 12 bytes long message and the daemon
> answers. On FreeBSD, on the other hand:
>
> 75838 acushare RET linux_ipc 12/0xc
> 75838 acushare CALL linux_getpid
> 75838 acushare RET linux_getpid 75838/0x1283e
> 75838 acushare CALL linux_ipc(0xe,0x50000,0x102,0,0xbfbff444,0)
> 75838 acushare RET linux_ipc -1 errno 22 Invalid argument
> 75838 acushare CALL linux_time(0xbfbff49c)
> 75838 acushare RET linux_time 1075830865/0x401fe051
> 75838 acushare CALL write(0,0x2806f000,0x4a)
> 75838 acushare GIO fd 0 wrote 74 bytes
> "acushare: 2004-02-03 18:54:25: Error replying to test message from run\
> cbl
> "
>
> That is, linux_ipc (possibly a catch-all name for the Linux IPC
> functions family), returns a 12 bytes long message, but when it is
> supposed to do the msgctl it fails miserably with an errno 22.
>
> I couldn't make sense out of the six arguments to linux_ipc shown in
> the kdump. Does anyone know how to interprete them?
linux_ipc is emulated in /sys/<machine>/linux/linux_machdep.c, and in
linux.h:
#define LINUX_MSGCTL 14
so the switch() in linux_ipc ends up calling linux_msgctl in
/sys/compat/linux/linux_ipc.c.
Do you have SYSV message queues enabled in your kernel? Stick "options
SYSVMSG" in your config file and rebuild, or "kldload sysvmsg" if you
have the module.
If you do have sysvmsg loaded, you may have to start adding printfs in
linux_msgctl() to trace which call is failing and why.
--
Dan Nelson
dnelson at allantgroup.com
More information about the freebsd-questions
mailing list