[haiku-development] Re: chroot and package daemon bug
- From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 16 Aug 2016 22:46:11 +0200
On Fri, Aug 12, 2016 at 09:02:32PM +0200, Ingo Weinhold wrote:
On 08/11/2016 10:38 PM, Adrien Destugues wrote:
You can just
struct stat st;
stat("/", &st);
and use (st.st_dev, st.st_ino) (a node_ref).
2) The vnode (or most likely, the dev and inode numbers) are sent to the
package daemon in GetInstallLocationInfo
3) The package daemon uses the given node as a root, instead of using
the default fSystemRoot (PackageDaemon.cpp:87)
4) The correct package dirs are returned, the code works as expected.
Sounds good.
Attached is what I have so far. It turned out a bit more complex on
package daemon side:
- I tried to create a Root and a Volume on the fly when the request is
sent. As far as I can see, the Root being a chroot, there is no mount
notification when it is created. I'm not sure if the package daemon
can infer the root when it sees a volume being created.
- I tried passing the request to the Volume directly, but 1) this is not
allowed as per comments in Root and Volume (operations on the Volume
should always run in the Root's job worker thread), and 2) it doesn't
work anyway because populating the volume with the list of packages is
done in the job queue, and there is no way to wait for that operation
to complete.
- So, I changed the Root class to process the request asynchronously by
posting it to the job queue. This serializes things as designed and
possibly fixes other concurrency problems.
With these changes, a normal findpaths -r still works (without crashing
anything). However, findpaths -r ran inside a chroot will crash because
of an unhandled exception when processing the reply.
This turned out a bit difficult to debug because of Debugger being a bit
confused by the chroot:
- I tried to run Debugger inside the chroot. In that case, I can't get
the "locate source" filepanel to show the chroot contents. It looks
like libtracker will query the list of mounted volumes from the mount
server, leanding to a similar issue to the one I'm trying to fix
(another way to escape the chroot). However, Debugger does not manage
to open the file, possibly because there is a conversion from node_ref
to path somewhere between the filepanel and trying to load the file.
- I also tried to run Debugger outside the chroot, and attach it to the
findpaths process after it is started. In that case, I can access the
sources, but Debugger doesn't manage to load the binary and libs so
the source view stays empty.
I tried to gather some info with just the variables view, but this is
not easy.
Unless someone can see what I missed in the patch, the next step will be
adding some exception handling in findpaths or the package kit, and
catch and interpret the error (it would be nice if abort() could trigger
the debug_server, btw, so unhandled exceptions would be easier to
catch).
I let the issues with Debugger and the libtracker/mount_server
interactions aside for now.
--
Adrien.
Other related posts:
