Skip to content

Extend trackedlock checking to jrpcfs and ramswift.#265

Open
charmster wants to merge 2 commits intodevelopmentfrom
bugfix-trackedlock
Open

Extend trackedlock checking to jrpcfs and ramswift.#265
charmster wants to merge 2 commits intodevelopmentfrom
bugfix-trackedlock

Conversation

@charmster
Copy link
Contributor

The jrpcfs package was missed in the original conversion of
sync.Mutex --> trackedlock.Mutex. catch it now.

ramswift already uses trackedlock, but if it was invoked as a
standalone daemon (as jrpcclient tests do), then trackedlocks
cannot be enabled from a config file. Fix that. When ramswift
is embedded in another test, it was already possible to enable
lock tracking for that test.

craig harmer added 2 commits March 2, 2019 23:08
The jrpcfs package was missed in the original conversion of
sync.Mutex --> trackedlock.Mutex.  catch it now.

ramswift already uses trackedlock, but if it was invoked as a
standalone daemon (as jrpcclient tests do), then trackedlocks
cannot be enabled from a config file.  Fix that.  When ramswift
is embedded in another test, it was already possible to enable
lock tracking for that test.
….log.

the jrpcclent unit test, and one other(?), use a stand-alone ramswift
process which, thanks to recent changes, now call Up() on the logger
which then tries to create the Logfile (if one is specified).

unit tests can not/should not try to create /var/log/proxyfs/proxfsd.log,
so change the config file used by the unit tests,
ramswift/saioramswift0.conf, to override the settins it inherits and
specify there is no log file (console output only).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant