Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creation of sapuc standard filebuf failed #356

Open
DiCheshirka opened this issue Feb 9, 2024 · 4 comments
Open

Creation of sapuc standard filebuf failed #356

DiCheshirka opened this issue Feb 9, 2024 · 4 comments
Assignees
Labels

Comments

@DiCheshirka
Copy link

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

@bsrdjan
Copy link
Contributor

bsrdjan commented Feb 9, 2024

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 bsrdjan self-assigned this Feb 9, 2024
@MisterGG
Copy link

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
[...]

@bsrdjan
Copy link
Contributor

bsrdjan commented Mar 28, 2024

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

@jchatin
Copy link

jchatin commented May 2, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants