-
Notifications
You must be signed in to change notification settings - Fork 575
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
snap-exec: fix detection if cups
interface is connected
#11616
Conversation
The cups interface needs a way to set the environment variable `CUPS_SERVER` if the `cups` interface is connected. However we have no mechanism for setting environment vars based on interface connections currently. To workaround this, the cups work added a workaround in `snap-exec` that tried to detect if `cups` is connected and when it is set the environment. Unfortunately the code in there was too simplistic because it just checked if the directory `/var/cups` exists. However ths dir now always exists because it's needed as the mount point. This commit fixes the detection by checking if `/var/cups` is a bind mount. This is checked by looking at the `stat()` data and the `dev_t` field in there. If they differ it means the bind mount exists and the only thing that creates this bind mount is the `cups` `MountConnectedPlug()` code. This is not great but it fixes the spread failure we see in the `cups-control` test (which is a real bug) and should be good enough until we have a proper interface backend that can set environment variables.
For unknown reasons the error message on unplug changes when I run this on my 20.04 system so I updated the tests - this may need more investigation.
dedeb7e
to
c38706c
Compare
@@ -74,4 +72,4 @@ execute: | | |||
echo "Expected error with plug disconnected" | |||
exit 1 | |||
fi | |||
MATCH "scheduler not responding" < print.error | |||
MATCH "(scheduler not responding|No default destination)" < print.error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw, this seems to be needed because the test-snapd-cups-control-consumer
moved to base: core20
very recently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thanks for the fix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
@mvo5 I have done a quick test:
I have updated to today's snapshot of snapd from Edge, which, identifying by the commit ID in the version number is from a commit AFTER the commit which is the merge of this PR. After that I have stopped and started again the CUPS Snap which is on my system, a local build of the current GIT status of the CUPS Snap. Due to the new snapd with this PR merged, the |
@mvo5 I have also a Snap which plugs
So for Snaps plugging I am wondering what the problem with the CUPS Snap is. |
Locally rebuilding the CUPS Snap did not solve the problem. |
This is a Snap which actually plugs
All correct here, only the CUPS Snap itself is doing wrong ... |
In which cases the code in |
I have now done the following: I have removed all the three Snaps, ... and this solved the problem!!! I retested all the three Snaps as in my posts above, getting the same (correct) result for Conclusions Principally, the bug is fixed. But what I am wondering about now is that if at some point in time in a Snap's sandbox an environment variable is set, that it seems to survive restarts, stopping and starting, updates of both the Snap itself and of snapd, ... in some cache where I have no idea where it is (it seems not to be in Then I would suggest that if WDYT? |
And by the way, I tested |
The cups interface needs a way to set the environment variable
CUPS_SERVER
if thecups
interface is connected. However wehave no mechanism for setting environment vars based on interface
connections currently. To workaround this, the cups work added
a workaround in
snap-exec
that tried to detect ifcups
isconnected and when it is set the environment. Unfortunately the
code in there was too simplistic because it just checked if
the directory
/var/cups
exists. However ths dir now alwaysexists because it's needed as the mount point.
This commit fixes the detection by checking if
/var/cups
isa bind mount. This is checked by looking at the
stat()
dataand the
dev_t
field in there. If they differ it means thebind mount exists and the only thing that creates this bind
mount is the
cups
MountConnectedPlug()
code.This is not great but it fixes the spread failure we see
in the
cups-control
test (which is a real bug) and shouldbe good enough until we have a proper interface backend that
can set environment variables.