bareos icon indicating copy to clipboard operation
bareos copied to clipboard

Python director plugin stalls job when importing os/requests.

Open matthijs opened this issue 1 year ago • 3 comments

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))

matthijs avatar Mar 19 '25 14:03 matthijs

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).

joergsteffens avatar Mar 19 '25 16:03 joergsteffens

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.

matthijs avatar Mar 20 '25 07:03 matthijs

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 avatar Mar 25 '25 22:03 readme79

@readme79 @matthijs can you tell us if the certificate you're using for your external monitoring system is self-signed ?

bruno-at-bareos avatar Jun 24 '25 08:06 bruno-at-bareos

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.

sebsura avatar Aug 04 '25 09:08 sebsura