View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001340bareos-corestorage daemonpublic2021-04-19 20:372023-12-13 15:28
Reporteregres Assigned Tobruno-at-bareos  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionduplicate 
PlatformLinuxOSUbuntuOS Version16.04
Product Version20.0.1 
Summary0001340: problem with Droplet Storage Backend
DescriptionJust 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 ReproduceConfigure 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
Tagsaws, crash, droplet, s3, storage

Relationships

duplicate of 0001553 closedarogge S3 (droplet) returns an error on Exoscale S3 service 

Activities

egres

egres

2021-04-19 20:53

reporter   ~0004113

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

Issue History

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