|
Package: singularity-container Version: 3.5.2+ds2-1 Severity: important On Debian 11 note this comes from debian-unstable. I am attempting to activate a singularity squashfs image from a script that runs at boot time. Singularity segfaults with the attached debug/traceback in the attached file portmanager Here is the tail of that file in case the bug reporting system does not support attachments: [0mDEBUG [0m[U=0,P=1210] Init() Check for sif image format [0mDEBUG [0m[U=0,P=1210] Init() sif format initializer returned: SIF magic not found [0mDEBUG [0m[U=0,P=1210] Init() Check for squashfs image format [0mDEBUG [0m[U=0,P=1210] Init() squashfs image format detected [0mDEBUG [0m[U=0,P=1210] setSessionLayer() Overlay seems supported and allowed by kernel [0mDEBUG [0m[U=0,P=1210] setSessionLayer() Attempting to use overlayfs (enable overlay = try) panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x606f8a] goroutine 7 [running]: github.com/sylabs/singularity/internal/pkg/runtime/engine/config/starter.(*Config).SetCapabilities(0xc0000109c8, {0x8e7c7e, 0x0}, {0xc00046eb00, 0x29, 0x0}) /build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/internal/pkg/runtime/engine/config/starter/starter_linux.go:403 +0x26a github.com/sylabs/singularity/internal/pkg/runtime/engine/singularity.(*EngineOperations).PrepareConfig(0xc0003b7d60, 0xc0000109c8) /build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/internal/pkg/runtime/engine/singularity/prepare_linux.go:140 +0x5ab github.com/sylabs/singularity/internal/app/starter.StageOne(0x988d40, 0xc00000ed08) /build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/internal/app/starter/stage_linux.go:27 +0x6a main.startup() /build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/cmd/starter/main_linux.go:56 +0x1ed created by main.main /build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/cmd/starter/main_linux.go:102 +0x25 VERBOSE [U=0,P=835] wait_child() stage 1 exited with status 2 [0m Once the system is booted, I can activate the image in the same way with no problem (same command). I can even do this as an unprivileged user. Here are excerpts from the script which show what I'm doing when that happens: #!/bin/sh ### BEGIN INIT INFO # Provides: nscldaq # Required-Start: $network $time $named $remote_fs $syslog # Required-Stop: $network $time $named $remote_fs $syslog # Should-Start: nscldaq # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: NSCL data acquisition daemons # Description: NSCL data acquisition daemons ### END INIT INFO export _SYSTEMCTL_SKIP_REDIRECT=true ... ## # Some definitions: # # We run the port manager and the ring master under the following singularity container # with BUSTEROPT bound to /usr/opt SINGULARITY_CONTAINER="/usr/opt/nscl-buster.img" USROPT="/usr/opt/opt-buster" ... PIDDIR="/scratch/nscldaq/run" LOGDIR="/scratch/nscldaq/log" DAQHOME="/usr/opt/daq/current" DAQBIN="${DAQHOME}/bin" DAQPORTMANAGER="${DAQBIN}/DaqPortManager" DAQPORTMANAGERPIDFILE="${PIDDIR}/portmgr.pid" DAQPORTMANAGERLOGFILE="${LOGDIR}/portmgr.log" ... start_portmanager() { nohup singularity -d exec --bind ${USROPT}:/usr/opt,/scratch --no-home ${SINGULARITY_CONTAINER} \ ${DAQPORTMANAGER} \ -log ${DAQPORTMANAGERLOGFILE} \ -pidfile ${DAQPORTMANAGERPIDFILE} \ </dev/null >/scratch/portmanager 2>&1 & log_daemon_msg portmanager sleep 3 # Let the port manager start. } Note that I have attempted to do the same thing after converting the container image to a .sif file and that too failed with essentially the same result. Thank you for any help you might be able to provide. I'd be happy to provide any additional information. Ron. |
Attachment:
portmanager
Description: portmanager