Python director plugin stalls job when importing os/requests.
Bareos component version
Bareos director:
# bareos-dir --version
24.0.2~pre41.988426cda
The director has one plugin which sends monitoring information to graylog (using the requests library from python).
Bareos storage:
# bareos-sd --version
24.0.2~pre41.988426cda
Bareos filedaemon:
# bareos-fd --version
24.0.2~pre41.988426cda
Steps to reproduce
On the director use the following config:
Director {
[..]
Maximum Concurrent Jobs = 2 # this is explicitly set to 2 for debugging.
Plugin Directory = /usr/lib/bareos/plugins
Plugin Names = "python3"
}
Job {
[..]
DIR Plugin Options = "python3:instance=0:module_name=bareos-dir-class-plugin"
}
In the default file included in the package: BareosDirPluginBaseclass.py put a line with:
import requests
The first two jobs will succeed without any problem. And the third job wil stay in 'is waiting execution', I've waited for over half an hour but the job never started. At the time I did the test there were no jobs running at all.
Expected results
I expect that the job to run.
Actual results
The job did not get processed. It is stuck in the 'is waiting execution' state.
Environment
- OS: `Debian GNU/Linux 12 (bookworm)`
Relevant log output
Relevant traces output
Anything else?
This all started when I did the upgrade from Bullseye to Bookworm (OS upgrade).
That did a python upgrade from version 3.9.2 to 3.11.2.
Another observation: the script did execute and we did see the relevant information in our monitoring system.
I still need to fetch the relevant traces. Will do that later this evening.
The last thing I want to point out: I've tried to reach out to the mailinglist at ([email protected]) but I couldn't get my message through. (I've sent it at 2025-03-11 16:00 (UTC+1))
The last thing I want to point out: I've tried to reach out to the mailinglist at ([email protected]) but I couldn't get my message through. (I've sent it at 2025-03-11 16:00 (UTC+1))
I don't see any blocked messages there. Can you give some more details, eg. have you received a bounce message or no reaction at all? What have been your sender address? If you don't want to share these info in this issue, you may send it to [email protected] (and add a note: as required by Jörg Steffens).
Hi Jörg,
Here is the line from my mail logs that it is delivered:
Mar 11 16:00:22 ctrl01 postfix/smtp[3374941]: A165F157900CF: to=<[email protected]>, relay=gmr-smtp-in.l.google.com[2a00:1450:4025:402::e]:25, delay=1.5, delays=0/0/0.73/0.74, dsn=2.0.0, status=sent (250 2.0.0 OK 1741705222 38308e7fff4ca-30bf7917307si1557801fa.1 - gsmtp)
I also didn't receive a bounce message.
I had the same problem. Not only requests, but also importing other packages (uuid, tzlocal) caused the same problem. As an alternative, I changed the uuid, tzlocal, requests import to http.client package instead of requests.
@readme79 @matthijs can you tell us if the certificate you're using for your external monitoring system is self-signed ?
This is a known bug with our use of python subinterpreters. Currently we are testing a solution for filedaemon python plugins (see the grpc plugin). Currently we dont see a lot of people asking for director plugins, but if that changes we could also develop a grpc plugin for the director.