Replies: 2 comments 18 replies
-
|
Could you try and remove "restart: unless-stopped" from your compose-file and check the logs again? Then it should not restart automatically and you might see the issue. Also with LOG_LEVEL=info some information might not even be shown in the logs, try different values like error or debug for LOG_LEVEL and check again |
Beta Was this translation helpful? Give feedback.
-
|
Ditto. I have the same issue on docker in vaultwarden 1.33.2 on a ubuntu 24.0.1 LTS. Previously working configuration is now broken despite there being no interaction with the server or underlying hardware. Vaultwarden exits with code 135 and there are no error logs, even when the most verbose logging is enabled. In my case, I can navigate to the login page, but when the password is submitted, vaultwarden immediately crashes with 135, completely preventing the ability to log in. I've bisected the docker images to get me past the login in 1.32.5 and break on 1.32.6. At least on my system, the API calls to the following paths (which happen as part of the login process) will cause the server to immediately crash with the last know log being a call to either of those two endpoints.
Right now I'll just have vaultwarden pinned to the working version until the bug is fixed. Since I'm running the docker container in VM across varying hardware on proxmox, I suspect that there might be subtle bugs that only show up due to the underlying hypervisor/host configuration as well. |
Beta Was this translation helpful? Give feedback.
-
|
Yep I do have that and I keep half hourly backup/snapshots to minimize risk of data loss in event of corruption. And update to the above - it seems that enforcing |
Beta Was this translation helpful? Give feedback.
-
|
Are you enforcing that on the Docker Host? NFS server or in the container somehow? |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Okay. I've tested The existing /etc/fstab setting that has worked for years was: I modified it to: Then I tried: Then I tried: Then I tried: For each attempt, I restarted the VM. Am I missing something? Also, Is there a way for me to check the integrity of the Vault database? What's weird is that I'm able to still use Vaultwarden for a split second before it restarts. For example, if I need to enter a new login, I'll be able to do it if I simply mash the save button. That means that the database is being written to but the server itself is unstable. |
Beta Was this translation helpful? Give feedback.
-
|
I would try to isolate the problem off nfs by copying the database to a local filesystem to see if it works on that (that's what I did). Perhaps your problem is different from mine. I believe there are sqlite commands that can do a database integrity check of the sqlite file format. I'm not sure if there are any tools that can check the integrity of the database contents themselves. |
Beta Was this translation helpful? Give feedback.
-
Hello all. Wondering if there is any help available out there. Thank in advance for any pointers or advice!
Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Config:
{ "_duo_akey": null, "_enable_duo": true, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": true, "_icon_service_csp": "", "_icon_service_url": "", "_ip_header_enabled": true, "_max_note_size": 10000, "_smtp_img_src": "***:", "admin_ratelimit_max_burst": 10, "admin_ratelimit_seconds": 60, "admin_session_lifetime": 20, "admin_token": "***", "allowed_connect_src": "", "allowed_iframe_ancestors": "", "attachments_folder": "data/attachments", "auth_request_purge_schedule": "30 * * * * *", "authenticator_disable_time_drift": false, "data_folder": "data", "database_conn_init": "", "database_max_conns": 10, "database_timeout": 30, "database_url": "***************", "db_connection_retries": 15, "disable_2fa_remember": false, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://**********************", "domain_origin": "*****://**********************", "domain_path": "", "domain_set": true, "duo_context_purge_schedule": "30 * * * * *", "duo_host": null, "duo_ikey": null, "duo_skey": null, "duo_use_iframe": false, "email_2fa_auto_fallback": false, "email_2fa_enforce_on_verified_invite": false, "email_attempts_limit": 3, "email_change_allowed": true, "email_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": true, "emergency_notification_reminder_schedule": "0 3 * * * *", "emergency_request_timeout_schedule": "0 7 * * * *", "enable_db_wal": true, "enable_websocket": true, "enforce_single_org_with_reset_pw_policy": false, "event_cleanup_schedule": "0 10 0 * * *", "events_days_retain": null, "experimental_client_feature_flags": "fido2-vault-credentials", "extended_logging": true, "helo_name": null, "hibp_api_key": null, "http_request_block_non_global_ips": true, "http_request_block_regex": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "icon_redirect_code": 302, "icon_service": "internal", "incomplete_2fa_schedule": "30 * * * * *", "incomplete_2fa_time_limit": 3, "increase_note_size_limit": false, "invitation_expiration_hours": 120, "invitation_org_name": "Vaultwarden", "invitations_allowed": true, "ip_header": "X-Real-IP", "job_poll_interval_ms": 30000, "log_file": null, "log_level": "info", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "login_ratelimit_max_burst": 10, "login_ratelimit_seconds": 60, "org_attachment_limit": null, "org_creation_users": "", "org_events_enabled": false, "org_groups_enabled": false, "password_hints_allowed": true, "password_iterations": 600000, "push_enabled": false, "push_identity_uri": "https://identity.bitwarden.com", "push_installation_id": "***", "push_installation_key": "***", "push_relay_uri": "https://push.bitwarden.com", "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sendmail_command": null, "sends_allowed": true, "sends_folder": "data/sends", "show_password_hint": false, "signups_allowed": false, "signups_domains_whitelist": "", "signups_verify": true, "signups_verify_resend_limit": 5, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": "\"Plain\"", "smtp_debug": false, "smtp_embed_images": true, "smtp_explicit_tls": null, "smtp_from": "*************************", "smtp_from_name": "W*****BitWarden", "smtp_host": "****************", "smtp_password": "***", "smtp_port": 587, "smtp_security": "starttls", "smtp_ssl": null, "smtp_timeout": 15, "smtp_username": "****************", "templates_folder": "data/templates", "tmp_folder": "data/tmp", "trash_auto_delete_days": null, "trash_purge_schedule": "0 5 0 * * *", "use_sendmail": false, "use_syslog": false, "user_attachment_limit": null, "user_send_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null }Vaultwarden Build Version
v1.33.2
Deployment method
Official Container Image
Docker version 27.5.1, build 9f9e405
Custom deployment method
Reverse Proxy
nginx external to the vaultwarden instance
Host/Server Operating System
Linux
Operating System Version
Ubuntu 24.04.1 LTS
Clients
Web Vault
Client Version
No response
Steps To Reproduce
I'm not sure because this problem started recently. Watchtower keeps things updated. The last time I thought I had an issue, when I tracked down a possible resolution, I added the ROCKET_ADDRESS=0.0.0.0 to my environment variables and it seems to resolve.
Actual Result
User is logged out from Web Vault.
Unable to log back in sometimes. You can mash the login button and get lucky.
Logs in browser console:
vaultwarden-1739616649170.log
Rocket
Logs
The logs repeat this over and over again. Sometime you can see a login but then it restarts over and over again.
Additional Context
I've been running Vaultwarden for some time now (like 4-5 years I think). For the most part, it's been able to run on autopilot but recently, it's been constantly resetting and I can't figure out why. The logs don't show anything even in Trace mode. The only other clue I have is that if I turn off restart: unless-stopped and set it to restart: no, I get an exit code of 135.
Doing some online research, it seems like code 135 is some sort of system issue but I've got plenty of RAM, CPU and SSD space (I'm running Ubuntu on Proxmox. The Ubuntu server is running 6CPU, 32GB RAM and I've got plenty of SSD left. Again, this has been running forever without issue. Are their any additional, NON-DISTRUCTIVE, methods of testing things out? I have backups but I'd REALLY rather not have to start from scratch on this.
Here is my Compose file as well:
I enable tracing on the logs and found this:
It seems like it gets up and running and then something causes it to restart but there is no error flagged?
Beta Was this translation helpful? Give feedback.
All reactions