Created attachment 175012 [details] v1 patch # update & fixes - use upstream mlock (verified to work) - add vault tag in process name to daemon(8) - update version tag from portstree Makefile In the end I left the daemon restart & pid management flags alone, until I can replicate the issue I had in production -- changing it seem to make matters worse and the vault is anyway sealed until admins re-open it. # qa - poudriere OK (11.0-RC3 amd64, 10.3R amd64 & i386, 9.3R amd64 & i386) - portlint OK - confirmed mlock works when using daemon & dropped privileges: ``` # limits -C daemon su -m vault -c 'sh -c "/usr/local/bin/vault server -config=/usr/local/etc/vault.hcl | tee -a /var/log/vault/console.log"' ==> Vault server configuration: Backend: s3 Listener 1: tcp (addr: "0.0.0.0:8200", cluster address: "", tls: "enabled") Log Level: info Mlock: supported: true, enabled: true Version: Vault v0.6.1 ==> Vault server started! Log data will stream in below: ``` incidentally if there is a logrotation friendly way to grab console data instead of tee(1) please let me know, the actual steps above did work, just no response from SIGHUP et al.
Created attachment 176682 [details] v2 patch for 0.6.2
# qa updates for v2 patch - poudriere OK (11.0R amd64, 10.3R amd64 & i386, 9.3R amd64 & i386)
A commit references this bug: Author: swills Date: Mon Nov 7 19:42:00 UTC 2016 New revision: 425642 URL: https://svnweb.freebsd.org/changeset/ports/425642 Log: security/vault: update to 6.2 PR: 212863 Submitted by: Dave Cottlehuber <dch@skunkwerks.at> (with modifications) Changes: head/security/vault/Makefile head/security/vault/distinfo head/security/vault/files/patch-helper_mlock_mlock__linux.go head/security/vault/files/patch-helper_mlock_mlock__solaris.go head/security/vault/files/patch-helper_mlock_mlock__unavail.go head/security/vault/files/patch-helper_mlock_mlock__unix.go head/security/vault/files/patch-version_version.go head/security/vault/files/vault.in
Committed, thanks!