XDG_RUNTIME_DIR set to a non-existing directory in sbuild
Bug #1964615 reported by
Michał Sawicz
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
launchpad-buildd |
Fix Released
|
High
|
Colin Watson | ||
schroot (Debian) |
Fix Released
|
Unknown
|
|||
schroot (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Starting yesterday we started seeing failures in different builds in a PPA:
https:/
I tracked it down to `XDG_RUNTIME_DIR` being set to `/run/user/$UID` all of a sudden. Some other variables also got set (comparison against a working build):
APT_CONFIG=
+DBUS_SESSION_
DEB_BUILD_
HOME=/
LANG=C.UTF-8
@@ -20,3 +21,7 @@
TERM=unknown
USER=buildd
V=1
+XDG_RUNTIME_
+XDG_SESSION_
+XDG_SESSION_ID=c81
+XDG_SESSION_
Related branches
~cjwatson/launchpad-buildd:systemd-service
- Ioana Lasc (community): Approve
-
Diff: 311 lines (+74/-152)10 files modifieddebian/changelog (+1/-0)
debian/control (+1/-1)
debian/launchpad-buildd-generator (+19/-0)
debian/launchpad-buildd.install (+1/-0)
debian/launchpad-buildd.maintscript (+1/-0)
debian/launchpad-buildd.service (+15/-0)
debian/launchpad-buildd@.service (+26/-0)
debian/postrm (+4/-0)
debian/rules (+6/-1)
dev/null (+0/-150)
description: | updated |
Changed in launchpad-buildd: | |
status: | New → In Progress |
importance: | Undecided → High |
assignee: | nobody → Colin Watson (cjwatson) |
Changed in schroot (Debian): | |
status: | Unknown → New |
Changed in schroot (Debian): | |
status: | New → Fix Released |
To post a comment you must log in.
This is extremely strange, and seems to be non-deterministic: different builders booted using the same VM image end up with different variables visible in launchpad-buildd's environment. My best guess is that the environment set up by su(1) is sensitive to some other bit of the boot process and thus causes launchpad-buildd's environment to vary depending on when it's started.
The simplest way to fix this may be to convert launchpad-buildd from an init script to a systemd service, since it's usually easier to control its environment that way: in particular, su(1) would no longer need to be involved.