On Sun, Dec 22, 2013 at 10:41 PM, Mike Shal <[email protected]> wrote:
> Hi Lee,
>
> On Fri, Dec 20, 2013 at 10:23 PM, Lee Winter <[email protected]>
> wrote:
>>
>> Recently I've been trying to use debug tools to understand what
>> happens to a software tool that is invoked by tup. But the
>> .tup/mnt/@tupjob-#/ directories have been impenetrable.
>>
>> In fuse_fs.c I've disabled the pgid check so that other process groups
>> should be able to access the fuse directories in the same way the
>> tup-launched software tool accesses those directories.
>
>
> How did you disable the pgid check? I tried to just do a 'return 0;' in
> context_check() and I am able to access the .tup/mnt directory. Doing 'ls
> .tup/mnt' should show the root file-system, as should 'ls
> .tup/mnt/@tupjob-X'.
Exactly. When context_check() always returns zero and the build step
takes forever then when I use ls -al I see:
in .tup/
all the typical .tup files and directories
mnt/
in .tup/mnt/
copies of all of the root files and directories but the link
counts differ slightly
NO SIGN OF @tupjob-#
I cannot detect @tupjob-#, (ls, df, etc.) but I can cd to it!
in tupjob-#/
duplicate of the contents of mnt/
My prompt shows .../.tup/mnt/@tupjob-#. And pwd show the same. So I
think the cd worked.
I expected to find only the build directories under
.../tup/mnt/@tupjob-#/, so seeing the root files there was a bit
disconcerting. Why are they in both .tup/mnt/ and in
.tup/mnt/tupjob-#/ ?
My /home/ is symlinked to /var/home/. So cding to /home/ within
.tup/mnt/@tupjob-#/ fails with "no such directory". But cding to
.tup/mnt/@tupjob-#//var/home works. And from there I can cd down to
the build step working directory.
The issues are:
1. the invisibility of @tupjob-# within .tup/mnt/
2. the presence of all the root files within /tup/mnt/@tupjob-#/
3. how to get fuse to follow symlinks so that they are safe to use
within the build tree.
>> However, I'm not able to see or access anything under .tup/mnt/ from
>> other contexts.
>>
>> I'm certain that the directories exist because a build tool that
>> prints pwd or navigates around the fuse file system does have
>> apparently normal access to the whole fuse directory tree.
>>
>> Why is it that other tools, not launched by tup, cannot even detect
>> the existence of the directories under .tup/mnt/?
>
>
> Just a quick sanity check - you do have tup running while you do this,
> right? The file-system is mounted on demand when running an update, and
> unmounted when tup exits. Probably the easiest way to check is to add a
> command that does a 'sleep 50' or some large number so that you have time to
> poke around the file-system.
Yes. I have loop waiting for a file (not in the build tree) to exist.
> What are you ultimately trying to determine? Aside from the @tupjob paths
> appearing in pwd, is there something not behaving as you would expect?
I am trying to understand the pgids seen by context_check() when other
programs access the build directory tree. Some of my debug tools do
not fit into a build step, so I need to run the build part way, pause
it, and then run the tools.
Eventually I hope to enhance context_check() so that it maintains a
(small) dynamic list of authorized pgids so external tools can be
used.
I am working on Debian 7.2.0 and using the tup sources from
approximately 2013-12-01.
Thanks for any light you can shed.
Lee Winter
Nashua, New Hampshire
United States of America
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
