libstore: always use the socket if it exists #4263
Conversation
This change modifies the behaviour of Nix to always communicate with the daemon, even if the store is writable to that user. Bypassing the daemon had a number of issues. Mainly, the client behaviour is not always consistent between users leading to confusion. The max-jobs counter is not shared between various instances of the Nix client. The clients fight between each-other to hold the lock on the sqlite database. By making the access consistent, it opens the road for the daemon to permanently hold the lock on the sqlite database, and get rid of the "sqlite is busy" type of errors.
|
This makes Nix less efficient when running as root, by requiring an unnecessary redirection through the daemon.
Not until we have a multi-threaded, non-forking daemon... |
Do you use |
|
No, but Hydra connects to most build slaves as root. |
|
This doesn't feel right. Maybe the daemon could be disabled on those machines but that doesn't strike me as a good solution either. Would you be willing to re-consider that decision if the daemon overhead was reduced sufficiently? |
|
What is the overhead that you are talking about? I assume it is all the
store data going through the Unix socket before going to the filesystem?
…On Tue, 17 Nov 2020, 12:07 Jonas Chevalier, ***@***.***> wrote:
This doesn't feel right. Maybe the daemon could be disabled on those
machines but that doesn't strike me as a good solution either.
Would you be willing to re-consider that decision if the daemon overhead
was reduced sufficiently?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4263 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE365CDGKYALLSZSZK7CBTSQJKOFANCNFSM4TW3TLMA>
.
|
|
I guess the next step would be to write some sort of benchmarks then. |
|
Having an option to run something one time with a different NIX_CONF_DIR and nix.conf without messing with the main daemon is what I find a feature, not a bug… I'd assume that for |
|
The overhead is having to start another process and send all operations to it via RPC. What's the actual problem here? I'm not really aware of issues caused by not going through the daemon. In particular
is not solved by this patch because the daemon worker processes don't share max-jobs or SQLite locks either. |
|
I marked this as stale due to inactivity. → More info |
|
I closed this issue due to inactivity. → More info |
This change modifies the behaviour of Nix to always communicate with the
daemon, even if the store is writable to that user.
Bypassing the daemon had a number of issues. Mainly, the client
behaviour is not always consistent between users leading to confusion.
The max-jobs counter is not shared between various instances of the Nix
client. The clients fight between each-other to hold the lock on the
sqlite database.
By making the access consistent, it opens the road for the daemon to
permanently hold the lock on the sqlite database, and get rid of the
"sqlite is busy" type of errors.