systemd: allow only a single daemon-reload at the same time #6243
Conversation
|
This was green in https://travis-ci.org/snapcore/snapd/jobs/461360585 |
Co-Authored-By: mvo5 <michael.vogt@gmail.com>
|
And green again |
|
Restarted once more. |
|
I just ran this on google:ubuntu-18.04-64 again and it passed there too. |
|
I'm very optimistic about this :) |
|
Run it yet again in google:ubuntu-18.04-64 - still no error. I guess we can start thinking about how we can do something like this the right way(tm) now so that we can integrate it proper. |
|
I think this is good to go. We want to have this, either in the current form or in some changed form down the line. LGTM |
| @@ -32,7 +33,12 @@ import ( | |||
| "github.com/snapcore/snapd/systemd" | |||
| ) | |||
|
|
|||
| var GML = &sync.Mutex{} | |||
There was a problem hiding this comment.
Could you please add a comment describing the problem it solves?
This works around the systemd bug systemd/systemd#10872 by ensuring that there is only a single operation that manipulates mount units at the same time.
| // mountLock ensures there is only a single concurrent mountunit | ||
| // operation. This works around this systemd bug: | ||
| // https://github.com/systemd/systemd/issues/10872 | ||
| mountLock sync.Mutex |
There was a problem hiding this comment.
I think go vet explodes on this, we really need to pass Backend around as a pointer with this change
|
Needs more work as Samuele pointed out that we may need to disallow all daemon-reloads - its not clear if the nature of the bug is that there can be no extra mount units added (but multiple daemon-reloads are ok) or if when a mount unit is added only a single daemon reload is ok. |
|
This was the discussion @mvo5 mentioned: |
|
Closing this one as the rabbit hole is deeper and we need to ensure we don't do any daemon reloads in parallel with writing mount units. I will push a new PR soon. |
This is an RFC PR to see if the "mount protocol error" reported in systemd/systemd#10872 can be worked around by serializing the mount unit adding/removal. Proposing to get full spread runs. This is similar to snapcore#6243 but it goes further by ensuring a single daemon reload on the systemd go package level. Note that there is still a chance that the protocol error happens if something else (like dpkg or the user) runs "systemd daemon-reload" while we write a mount unit. But the risk should be hughely smaller.
This is an RFC PR to see if the "mount protocol error" reported in systemd/systemd#10872 can be worked around by serializing the mount unit adding/removal. Proposing to get full spread runs. This is similar to snapcore#6243 but it goes further by ensuring a single daemon reload on the systemd go package level. Note that there is still a chance that the protocol error happens if something else (like dpkg or the user) runs "systemd daemon-reload" while we write a mount unit. But the risk should be hughely smaller.
This is an experiment to see if the "mount protocol error" reported in systemd/systemd#10872 can be worked around by serializing the mount unit adding/removal. Proposing to get full spread runs.