would ptrace work?

[David Roundy]

I've just been struggling with fuse errors on my work computer, where I wasn't originally a member of the fuse group, and I'm working on nfs... I still haven't figured out which of these caused the most errors, but things still aren't working.  I expect that if tup is packaged by Debian, many of these pains will go away.

However, I got to wondering if ptrace might serve.  If all you need is to trace syscalls, I think this could work on Linux anyhow.  The downside is that you'd need to make tup understand all system calls that would affect files.  The plus side would be that it would be much simpler and more robust in operation, since you wouldn't have to mount and unmount a fake filesystem, and it would work with statically linked executables (including ones that don't use libc).  The downside is that you might not be able to lie about readdir's results to convince executables that generated files don't exist.

Anyhow, just a few thoughts, after an hour or so of fruitless attempts to make tup work.

David

[Freddie Chopin]

Here is a post by Mike about different dependency tracking options -
there's also a chapter about ptrace().

http://gittup.org/blog/2014/05/7-clobber-builds-part-2---fixing-missing-dependencies/

What problems do you have? I've recently switched to Linux and I've
probably faced the same issues as you did, so maybe I'll be able to
help. I'm using Arch, so things may be a bit different.

Regards,
FCh

[David Roundy]

I am currently getting the error:

$ tup

Initializing .tup in /home/droundy/Sync/projects/deft

.tup repository initialized.

[ tup ] [0.150s] Scanning filesystem...

[ tup ] [0.679s] Reading in new environment variables...

[ tup ] [0.797s] Parsing Tupfiles...

.tup/mnt: Permission denied

 [                             ETA~=??? Remaining=81                               ]   0%

 *** tup: 1 job failed.

fusermount: failed to chdir to /home/droundy/Sync/projects/deft/.tup: Permission denied

tup error: Unable to unmount the fuse file-system on .tup/mnt (return code = 256). You may have to unmount this manually as root: umount -f .tup/mnt

To see the mount:

$ mount | grep tup

tup on /home/droundy/Sync/projects/deft/.tup/mnt type fuse.tup (rw,nosuid,nodev,relatime,user_id=1137,group_id=100)

Any attempt to use root to umount fails because this directory is not world-readable and lives on my NFS-mounted home directory, which is mounted with rootsquash.  (As is the only sane option.)

David

[David Roundy]

Running tup in a non-nfs directory on this machine fails with:

$ tup

Initializing .tup in /var/droundy/deft

.tup repository initialized.

[ tup ] [0.091s] Scanning filesystem...

[ tup ] [0.231s] Reading in new environment variables...

[ tup ] [0.323s] Parsing Tupfiles...

.tup/mnt: Permission denied

 [                        ETA~=??? Remaining=78                          ]   0%

 *** tup: 1 job failed.

I'm not sure what's up with that.  It doesn't leave the fuse filesystem mounted in this directory, however, so that at least is better, as it means at least I can delete the .tup directory afterwards.  I'm hesitant to adopt a build system that is this finicky.  I'm confident I can get it working one way or another (after all, tup works on my laptop), but having a build system that fails at all is bad, and when it fails in confusing ways that lead to un-removable directories, that's worse.

David

[Freddie Chopin]

Hmm... I won't help you much with the NFS issue, but for a "normal"
workflow I had to enable option "user_allow_other" in /etc/fuse.conf -
it was enough to uncomment it. Tup worked without that too, but using
^c^ flag caused an error.

Regards,
FCh

[David Roundy]

Hmmm.  That sounds like it's undermining a pretty important security setting, and I'm hesitant to do that on a multiuser machine.

David

Regards,
FCh

--
--
tup-users mailing list
email: tup-...@googlegroups.com
unsubscribe: tup-users+unsubscribe@googlegroups.com
options: http://groups.google.com/group/tup-users?hl=en
--- You received this message because you are subscribed to a topic in the Google Groups "tup-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tup-users/ApM3nxONDkg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tup-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

David Roundy

[Mike Shal]

The user_allow_other flag is only needed if you want to use full file-system wide dependencies, or run processes with the ^c flag to force running in a chroot. Otherwise you don't need to set it. If that is the problem, you should see something like this:

 --- Run t2000-basic-tupfile.sh ---
.tup repository initialized.
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.001s] Reading in new environment variables...
[ tup ] [0.001s] Parsing Tupfiles...
fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf

Since yours is failing with a different permission error, I'd guess something else is the problem. Is there a non-NFS mountpoint that you can try to use instead? Does that fail as well?

-Mike

unsubscribe: tup-users+...@googlegroups.com
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 tup-users+...@googlegroups.com.

[David Roundy]

Hi Mike,

Thanks for the clarification about the user_allow_other flag!

As far as I can see, the problem was actually that I was using syncthing to synchronize the directories that were a problem.  This didn't cause trouble on my laptop, but perhaps interacts poorly with NFS.

David

To unsubscribe from this group and all its topics, send an email to tup-users+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
David Roundy