PyRFC icon indicating copy to clipboard operation
PyRFC copied to clipboard

Creation of sapuc standard filebuf failed

Open DiCheshirka opened this issue 1 year ago • 4 comments

Describe the big SAP RFC calls from the Foresight platform scheduler do not work. The error "Creation of sapuc standard filebuf filed." occurs, the scheduler restarts. The problem only occurs on Linux, there is no such problem on Windows. Is it possible that the problem is on the library side?

To Reproduce Run any python script from the scheduler (not manually, but by a scheduled process):

import pyrfc
 print('Hello!')

Environment

  • OS: Linux
  • Running in docker?: No
  • PyRFC version: 3.1

**Additional content

DiCheshirka avatar Feb 09 '24 10:02 DiCheshirka

need some more info

  • Linux distro?
  • SAP NW RFC SDK version?
  • Python version?
  • Why old PyRFC 3.1 is used and how was it installed? The build from source is the only reliable way on Linux.

bsrdjan avatar Feb 09 '24 10:02 bsrdjan

Hi there, I have the same problem. Linux Distro: Ubuntu 22.04.3 LTS NW RFC Library Version: 750 Patch Level 12 Python 3.10.12 installed pyrfc-3.3-cp310-cp310-linux_x86_64.whl with pip

About one third of our pyrfc requests fail, so I traced them with strace and it seems to be a problem with the file descriptor:

connect(0, {sa_family=AF_UNIX, sun_path="/run/uuidd/request"}, 110) = 0 write(0, "\4\350\3\0\0", 5) = 5 read(0, "\24\0\0\0", 4) = 4 read(0, "\370\r\230\352\354\306\21\356\225\245\375_9\370\337\262\350\3\0\0", 20) = 20 close(0) = 0 fcntl(0, F_GETFL) = -1 EBADF (Bad file descriptor) fcntl(1, F_GETFL) = 0x1 (flags O_WRONLY) fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fcntl(2, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) fstat(2, {st_mode=S_IFREG|0664, st_size=150676, ...}) = 0 fcntl(2, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) fstat(2, {st_mode=S_IFREG|0664, st_size=150812, ...}) = 0 fcntl(0, F_GETFL) = -1 EBADF (Bad file descriptor) write(2, "Creation of sapuc standard fileb"..., 43Creation of sapuc standard filebuf failed. ) = 43 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 gettid() = 3298239 getpid() = 3298239 tgkill(3298239, 3298239, SIGABRT) = 0

If the request fails, the file descriptor in the first part is always 0. In the successfull requests, the file descriptor is 3:

connect(3, {sa_family=AF_UNIX, sun_path="/run/uuidd/request"}, 110) = 0 write(3, "\4\350\3\0\0", 5) = 5 read(3, "\24\0\0\0", 4) = 4 read(3, "\222L\301b\354\305\21\356\225}\375_9\370\337\262\350\3\0\0", 20) = 20 close(3) = 0 fcntl(0, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) fstat(0, {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}) = 0 fcntl(1, F_GETFL) = 0x1 (flags O_WRONLY) fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fcntl(2, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) fstat(2, {st_mode=S_IFREG|0664, st_size=151073, ...}) = 0 fcntl(2, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) fstat(2, {st_mode=S_IFREG|0664, st_size=151209, ...}) = 0 fcntl(0, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) fstat(0, {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}) = 0 fcntl(1, F_GETFL) = 0x1 (flags O_WRONLY) fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fcntl(2, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) fstat(2, {st_mode=S_IFREG|0664, st_size=151608, ...}) = 0 fcntl(1, F_GETFL) = 0x1 (flags O_WRONLY) fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 munmap(0x7f5af9ea5000, 37203) [...]

I followed the trace to the source of the file descriptor number and it seems to be determined by opening the /etc/ld.so.cache: Fail:

openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 0 newfstatat(0, "", {st_mode=S_IFREG|0644, st_size=37203, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 37203, PROT_READ, MAP_PRIVATE, 0, 0) = 0x7f721ddeb000 [...]

Success:

openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=37203, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 37203, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5afa15c000 [...]

MisterGG avatar Mar 28 '24 06:03 MisterGG

@MisterGG could you please crate new issue, describe PyRFC usage scenario and steps to reproduce

bsrdjan avatar Mar 28 '24 09:03 bsrdjan

Same issue when calling a python script as ExternalScript from Zabbix server I found that sometimes FD 0 is missing, and I have the same error in strace : fcntl(0, F_GETFL) = -1 EBADF (Bad file descriptor)

When the RFc call is working I have this trace : fcntl(0</dev/null >, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)

I found a workaround by calling the python script with stdin redirection to force FD 0 creation pythonscript </dev/null

jchatin avatar May 02 '24 12:05 jchatin