Closed chripede closed 1 month ago
Interesting. I can't really reproduce it, but I have pushed a fix for this. Please try the edge
tagged image once it has finished building in ~15 minutes.
That is, if you use the docker-compose from the README, replace image: ghcr.io/donkie/spoolman:latest
with image: ghcr.io/donkie/spoolman:edge
Will test new image
I am running it on unraid. Running with docker and the same params on my desktop I cannot reproduce it either.
FYI it seems the action failed to publish a new image, so I will not be testing until tomorrow :)
Now it succeeded :)
This is the warning that edge outputs
Failed to setup disk-based cache due to permission error. Ensure the path /home/app/spoolman/.cache/hishel is writable. Using in-memory cache instead as fallback.
Also this probably belongs in its own bug report, but it's late.
Importing filaments from the external database is a mess of
DETAIL: Key (id)=(3) already exists.
[SQL: INSERT INTO vendor (registered, name, empty_spool_weight, comment, external_id) VALUES ($1::TIMESTAMP WITHOUT TIME ZONE, $2::VARCHAR, $3::FLOAT, $4::VARCHAR, $5::VARCHAR) RETURNING vendor.id]
[parameters: (datetime.datetime(2024, 5, 20, 22, 54, 3), 'JAYO', None, None, 'JAYO')]
from both vendor keys and filament keys
I ran into this problem when I had PUID and PGID set to something other than 1000 and 1001, respectively, to match existing IDs on my system. This used to work with previous versions.
Restored PUID=1000 and PGID=1001 in my container's environment, and chown'ed the external volumes mounted into the container (chown 1000:1001 -R PATH/TO/SPOOLMAN/DATA
), and then the error was gone.
This is the warning that edge outputs
Failed to setup disk-based cache due to permission error. Ensure the path /home/app/spoolman/.cache/hishel is writable. Using in-memory cache instead as fallback.
Try latest image from edge tag now, the warning should no longer appear.
I have yet to look into the conflicting ID issue. I cant seem to reproduce it. Could you try some more and see if you can make it import for some cases but not others, etc?
You're probably using my unraid template for spoolman. You can mount the cache path as a workaround. See screenshot.
Don't know why spoolman always has some problems with permissions..
EDIT: the permission issue is probably with unraid using PUID and PGID 99:100 (and container is set up with variables to use this) but the .cache dir is probably created with something else (probably 1000:100?)
Just wanted to say I woke up this AM to this issue, switching to the edge release fixed it immediately.
You're probably using my unraid template for spoolman. You can mount the cache path as a workaround. See screenshot.
Don't know why spoolman always has some problems with permissions..
EDIT: the permission issue is probably with unraid using PUID and PGID 99:100 (and container is set up with variables to use this) but the .cache dir is probably created with something else (probably 1000:100?)
I changed the cache dir in the latest commit so now its located inside the spoolman data dir like everything else, there shouldnt be any permission issues anymore.
I will push an update when the other issue he mentioned is addressed
Having the same exact issue with latest. Trying edge now. Edge fixed the issue
docker-compose.yml is
services:
spoolman:
hostname: spoolman
container_name: spoolman
image: ghcr.io/donkie/spoolman:edge
restart: unless-stopped
volumes:
- /home/spoolman/data:/home/app/.local/share/spoolman
- /etc/letsencrypt/live/hallgren.net:/home/spoolman/app/certs/live/hallgren.net:ro
- /etc/letsencrypt/archive/hallgren.net:/home/spoolman/app/certs/archive/hallgren.net:ro
ports:
- 7912:8000
command: --host 0.0.0.0 --port 8000 --ssl-keyfile /home/spoolman/app/certs/live/hallgren.net/privkey.pem --ssl-certfile /home/spoolman/app/certs/live/hallgren.net/fullchain.pem
environment:
- TZ=America/Chicago # Optional, defaults to UTC
- PUID=1001
- PGID=1001
networks:
default:
external:
name: br0
does anyone else have the issue that @chripede had above with "DETAIL: Key (id)=(3) already exists." errors?
does anyone else have the issue that @chripede had above with "DETAIL: Key (id)=(3) already exists." errors?
My issue was mainly the cache no issues with duplicate keys but sounds like he's importing data so probably a separate issue.
The original problem has been solved for me now, thanks!
As for the unique key problem, I have created a new bug report with more info #384
I have now pushed 0.18.1 that fixes this issue in a stable release. Everyone who switched to edge
tag, please switch back to latest
, edge should never be used in a production environment since it can sometimes be broken.
Describe the bug Error during startup
Spoolman Host (please complete the following information):