# Juliaup configuration is locked by another process, waiting for it to unlock
**URL:** https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366
**Category:** General Usage
**Tags:** question, vscode, juliaup
**Created:** [October 16, 2024, 8:12am UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366 "2024-10-16T08:12:11Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [October 16, 2024, 8:12am UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/1 "2024-10-16T08:12:11Z")
Whenever I launch Julia in the bash terminal of VSCode in Ubuntu Linux I get the message:
```julia
Juliaup configuration is locked by another process, waiting for it to unlock.
```
What could be the reason?
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [October 16, 2024, 12:03pm UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/2 "2024-10-16T12:03:28Z")
You probably installed Julia through `juliaup`, the latter does show this message sometimes. I guess it tries to auto-update Julia or something?..
Official binary downloads don’t do that, they just always start immediately.
---
### Author:  [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)
#### Post date: [October 16, 2024, 12:14pm UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/3 "2024-10-16T12:14:37Z")
Looks like [Unlock configuration file during download · Issue #435 · JuliaLang/juliaup · GitHub](https://github.com/JuliaLang/juliaup/issues/435)
Or maybe [Don't lock the juliaup config file when only reading · Issue #561 · JuliaLang/juliaup · GitHub](https://github.com/JuliaLang/juliaup/issues/561)
And see [this comment](https://github.com/JuliaLang/juliaup/issues/598#issuecomment-1517757366) for a potential workaround.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [October 16, 2024, 12:30pm UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/4 "2024-10-16T12:30:51Z")
> [@aplavin](#):
>
> `juliaup`, the latter does show this message sometimes. I guess it tries to auto-update Julia or something
It does not always show this message. But I could not figure out yet when it does and when it doesn’t. Who might auto-update Julia? The VSCode language server? Or juliaup?
---
### Author:  [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)
#### Post date: [October 16, 2024, 2:15pm UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/5 "2024-10-16T14:15:34Z")
As far as I know juliaup doesn’t auto-update julia but it may auto-update itself and/or update the list of available julia releases.
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [October 16, 2024, 10:26pm UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/6 "2024-10-16T22:26:29Z")
Yes, Juliaup auto-updates itself and the list of available Julia versions. It will never update any Julia version itself without explicit opt-in from the user.
This locked message is annoying, I know how to fix it, just need to find the time to do it…
---
### Author:  [@jayprakashdav20](https://discourse.julialang.org/u/jayprakashdav20)
#### Post date: [June 9, 2026, 9:47am UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/7 "2026-06-09T09:47:22Z")
I am facing the same error now. My juliaup version is 1.20.4, julia version is 1.11.1 and operating system is Linux. Can someone suggest what is the working solution?
---
### Author:  [@Eben60](https://discourse.julialang.org/u/Eben60)
#### Post date: [June 9, 2026, 11:12am UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/8 "2026-06-09T11:12:40Z")
On a Mac
```julia-auto
be@HPH-iMac-02 ~ % juliaup --version
Juliaup 1.20.1
be@HPH-iMac-02 ~ % juliaup self update
Checking for new Julia versions
Checking for self-updates
Found new version 1.20.4 on channel release.
Juliaup configuration is locked by another process, waiting for it to unlock.
^C
be@HPH-iMac-02 ~ % juliaup self update
Checking for new Julia versions
Checking for self-updates
Juliaup unchanged on channel 'release' - 1.20.4
be@HPH-iMac-02 ~ %
```
The same thing was observed on my another Mac: [Juliaup cannot find Julia - #6 by Eben60](https://discourse.julialang.org/t/juliaup-cannot-find-julia/137462/6) - the `juliaup` self update apparently performed, but then the command stalled
---
### Author:  [@cdawg](https://discourse.julialang.org/u/cdawg)
#### Post date: [June 9, 2026, 12:59pm UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/10 "2026-06-09T12:59:23Z")
First time Ive gotten this error after many years, so seems to be a juliaup blip with the last update. Works fine after restarting the computer.
---
### Author:  [@jayprakashdav20](https://discourse.julialang.org/u/jayprakashdav20)
#### Post date: [June 9, 2026, 3:16pm UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/11 "2026-06-09T15:16:43Z")
Thank you for your responses. Unfortunately, I could not restart the server as it is used by several other people. What worked in my case was to kill all the Julia processes across multiple servers (a single disk storage is shared among 3 different servers). The kill command I used is pkill -U username -f bin/julia.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [June 9, 2026, 10:17pm UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/12 "2026-06-09T22:17:13Z")
It was a bug released, and already fixed, in juliaup
---
### Author:  [@sob](https://discourse.julialang.org/u/sob)
#### Post date: [June 9, 2026, 10:53pm UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/13 "2026-06-09T22:53:59Z")
I solved it by `killall juliaup`
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [June 10, 2026, 4:42am UTC](https://discourse.julialang.org/t/juliaup-configuration-is-locked-by-another-process-waiting-for-it-to-unlock/121366/14 "2026-06-10T04:42:54Z")
See
>
>
> Closes #435
> Closes #561
> Closes #1524
>
> Existing draft PRs
> Closes #1238
> Clos…es #1317
>
> Claude:
>
> \---
>
> Shrink the region covered by the global juliaup configuration lock so the network download/extract of a version no longer happens while the exclusive lock is held. The same pattern is now applied to every command that downloads:
>
> \- \*\*\`add\`\*\* — splits the old \`install\_version\` into \`download\_version\_to\_temp\` (lock-free, network-bound) and \`commit\_version\_install\` (lock-held, fast rename + config write).
> \- \*\*\`self update\`\*\* — reads the configured channel under a brief shared lock, releases it, downloads juliaup with no lock held, then re-acquires the exclusive lock only to record the timestamp.
> \- \*\*\`update\`\*\* — two-phase: snapshot the config under a shared lock, download all needed channels lock-free (\`prepare\_channel\_update\`), then take the exclusive lock once to commit them all (\`commit\_channel\_update\`).
> \- \`update\_version\_db\` already followed this pattern.
>
> In every case the commit phase re-checks the config (optimistic concurrency), so two processes acting on the same version/channel resolve cleanly (the loser discards its temp dir) rather than erroring.
>
> Also:
> \- The "configuration is locked by another process, waiting for it to unlock" message now only prints if the lock can't be acquired within a 1s grace period, suppressing spurious messages during the millisecond-scale commit phase.
> \- Adds https://github.com/JuliaLang/juliaup/blob/ib%2Freduce\_lock/devdocs/locking\_and\_update\_flows.md documenting the lock model and per-command flows with diagrams.
>
> Together these eliminate the long-lock-across-network pathology in the launcher's background daemon path (it spawns \`self update\` / versiondb update), which was the cause of the spurious lock stalls in #1524.
>
> How this honors the discussion (#435, #561):
> \- Implements davidanthoff's proposed design from #435: read config + release lock, download, then re-acquire and commit, instead of holding the write lock for the whole download.
> \- Honors LilithHafner's refinement: the commit phase re-checks whether the install is still needed.
> \- Keeps StefanKarpinski's shared/exclusive model: many readers coexist and only block for the millisecond-scale commit, not for a multi-minute download.
>
> Benefit over the other open PRs:
> \- vs #1238 (remove file locking entirely): juliaup performs multi-file operations (install dir + config + symlinks) that a single-file atomic rename cannot keep consistent. This retains the lock for cross-file consistency while still eliminating the long-lock pathology #1238 targets.
> \- vs #1317 (close config files right after read): complementary — that PR shortens how long handles stay open; this shortens how long the exclusive lock is held during the download.
and the issues linked there.