View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001340 | bareos-core | storage daemon | public | 2021-04-19 20:37 | 2023-12-13 15:28 |
| Reporter | egres | Assigned To | bruno-at-bareos | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | duplicate | ||
| Platform | Linux | OS | Ubuntu | OS Version | 16.04 |
| Product Version | 20.0.1 | ||||
| Summary | 0001340: problem with Droplet Storage Backend | ||||
| Description | Just upgraded from 19.2.7-2 with 20.0.1-3 without issue (thanks). My first try with S3 backend, so I might have missed something but this looks like a bug. My device configuration: ---- Device { Name = S3_ObjectStorage Media Type = S3_Object1 Archive Device = S3 Object Storage # testing: Device Options = "profile=/etc/bareos/bareos-sd.d/device/droplet/droplet.profile,storageclass=glacier,bucket=<my.bucket.name>,chunksize=100M,iothreads=0,retries=1" Device Type = droplet Label Media = yes # lets Bareos label unlabeled media Random Access = yes Automatic Mount = yes # when device opened, read it Removable Media = no Always Open = no Description = "S3 device" Maximum Concurrent Jobs = 1 } ---- My profile configuration: ---- host = s3.ca-central-1.amazonaws.com # also tried s3.amazonaws.com use_https = true access_key = "<access_key>" secret_key = "<secret_key>" pricing_dir = "" # If not empty, an droplet.csv file will be created which will record all S3 operations. backend = s3 aws_auth_sign_version = 4 # Currently, AWS S3 uses version 4. The Ceph S3 gateway uses version 2. aws_region = ca-central-1 ---- When I do a 'status storage' of my S3 storage device, I get the following status ---- Device status: Device "S3_ObjectStorage" (S3) is not open. Jmsg Job=*System* type=6 level=1618846576 bareos-sd: info: ../../../../../core/src/droplet/libdroplet/src/droplet.c:127: dpl_init: PRNG has been seeded with enough data ---- When I try to run a job, I get the following error ---- 19-Apr 11:32 client-fd JobId 62545: Fatal error: filed/dir_cmd.cc:2692 Comm error with SD. bad response to Append Data. ERR=Unknown error 19-Apr 11:32 bareos-dir JobId 62545: Fatal error: Director's comm line to SD dropped. 19-Apr 11:33 bareos-dir JobId 62545: Error: Bareos bareos-dir 20.0.1 (02Mar21): ---- In both cases, I see the following in Ubuntu's syslog file at the moment of the events ---- Apr 19 11:32:57 bareos bareos-dir: Connected Storage daemon at <ip>:9103, encryption: PSK-AES256-CBC-SHA TLSv1/SSLv3 Apr 19 11:32:57 bareos bareos-sd: BAREOS interrupted by signal 11: Segmentation violation Apr 19 11:32:57 bareos systemd[1]: bareos-storage.service: Main process exited, code=exited, status=1/FAILURE Apr 19 11:32:57 bareos systemd[1]: bareos-storage.service: Unit entered failed state. Apr 19 11:32:57 bareos systemd[1]: bareos-storage.service: Failed with result 'exit-code'. Apr 19 11:32:57 bareos systemd[1]: bareos-storage.service: Service hold-off time over, scheduling restart. Apr 19 11:32:57 bareos systemd[1]: Stopped Bareos Storage Daemon service. Apr 19 11:32:57 bareos systemd[1]: Starting Bareos Storage Daemon service... Apr 19 11:32:57 bareos systemd[1]: bareos-storage.service: Can't open PID file /var/lib/bareos/bareos-sd.9103.pid (yet?) after start: No such file or directory Apr 19 11:32:57 bareos systemd[1]: Started Bareos Storage Daemon service. ---- So it looks like the problem with the droplet library crashes bareos-sd and systemd restarts it automatically. I ran a job with my standard Storage and did not have an issue. The problem seems to be limited to the Droplet Storage Backend. | ||||
| Steps To Reproduce | Configure a Storage Device with Droplet Storage Backend as described. Run a job to the backend or 'status storage' has the effect of crashing bareos-sd with the message ---- BAREOS interrupted by signal 11: Segmentation violation ---- all the time | ||||
| Tags | aws, crash, droplet, s3, storage | ||||
| duplicate of | 0001553 | new | S3 (droplet) returns an error on Exoscale S3 service |
 |
Just realised, I initially wanted to test different storageclass and forgot about it afterwards After removing ---- ...,storageclass=glacier,... ---- I get the same problem as described in https://bugs.bareos.org/view.php?id=1331 It would be nice to document the supported storage classes. So this issue seems directly related to using an unsupported sotrageclass value (I guess). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-04-19 20:37 | egres | New Issue | |
| 2021-04-19 20:37 | egres | Tag Attached: crash | |
| 2021-04-19 20:37 | egres | Tag Attached: s3;droplet;aws | |
| 2021-04-19 20:37 | egres | Tag Attached: storage | |
| 2021-04-19 20:44 | egres | Tag Detached: s3;droplet;aws | |
| 2021-04-19 20:45 | egres | Tag Attached: s3 | |
| 2021-04-19 20:45 | egres | Tag Attached: droplet | |
| 2021-04-19 20:45 | egres | Tag Attached: aws | |
| 2021-04-19 20:53 | egres | Note Added: 0004113 | |
| 2023-12-13 15:28 | bruno-at-bareos | Assigned To | => bruno-at-bareos |
| 2023-12-13 15:28 | bruno-at-bareos | Status | new => closed |
| 2023-12-13 15:28 | bruno-at-bareos | Resolution | open => duplicate |
| 2023-12-13 15:28 | bruno-at-bareos | Relationship added | duplicate of 0001553 |
