Neil, thanks so much for checking this out!
That is interesting. I also tried another variant where I'd launch "emacs
--daemon" before running Tup, then issue "emacsclient" from the build
instead. In those cases I would see an outright message like "Operation
not permitted: cannot change directory"---even if I didn't do anything from
the client. Sounds like that was essentially the same issue.
>From my point of view, these are deterministic, file-based input-output
operations occurring within the build directory, so if Tup has to disallow
them I'd understand it as an implementation constraint. But I am quite out
of my depth with respect to the details of Linux's process model, and I
trust that the rule may be necessary.
As I said, I love Tup---so much that I'm migrating a major project over to
Linux after many years. That in itself is a good outcome. And I'm willing
to be a guinea pig who disables this restriction to see how things go. I
installed Tup from source so could comment out the relevant check.
Thanks again,
Gavin
On Saturday, June 20, 2015 at 10:06:49 AM UTC-5, Neil Shepperd wrote:
>
> Running emacs under strace, I got this interesting snippet:
>
> [pid 7700] vfork(Process 7702 attached
> <unfinished ...>
> [pid 7702] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> [pid 7702] setsid() = 7702
> [pid 7702] rt_sigaction(SIGPIPE, {SIG_DFL, [PIPE],
> SA_RESTORER|SA_RESTART, 0x7f90738215b0}, {SIG_DFL, [], 0}, 8) = 0
> [pid 7702] rt_sigaction(SIGPROF, {SIG_DFL, [PROF],
> SA_RESTORER|SA_RESTART, 0x7f90738215b0}, {SIG_IGN, [PROF],
> SA_RESTORER|SA_RESTART, 0x7f90738215b0}, 8) = 0
> [pid 7702] getpid() = 7702
> [pid 7702] chdir("/home/neil/ts/.tup/mnt/@tupjob-22/home/neil/ts") = -1
> EPERM (Operation not permitted)
> [pid 7702] exit_group(125) = ?
> [pid 7700] <... vfork resumed> ) = 7702
>
> It looks like after emacs forks, the child process makes itself leader of
> a new process group with setsid(), which trips tup's security restrictions
> on the fuse mountdir
>
> tup fuse warning: Process pid=7702, uid=1000, gid=1000 is trying to
> access the tup server's fuse filesystem.
>
> so access is denied for the child to chdir into the fuse dir.
>
> I suppose this is a bug, if we really want to allow child processes to put
> themselves into new process groups?
>
> Regards
> Neil
>
> On 19/06/15 00:57, Gavin Cannizzaro wrote:
> > Thanks for the reply, Bernhard.
> >
> > My understanding is that Tup will not export anything by default except
> PATH. Even so, I've tried the same tests with explicit command paths (like
> "/usr/bin/touch") with the same results. I wouldn't expect that coreutils
> like touch require any other environment variables, but it is at least
> something to investigate further.
> >
> > I also forgot to mention that emacs itself *can* write to files. So
> org-export, which I guess does its file access directly (from the C
> functions) does work. It's only when launching a sub-process (as is needed
> for org babel) that I run into this problem.
> >
> > Thanks again,
> > Gavin
> >
> >
> > On Thursday, June 18, 2015 at 9:29:30 AM UTC-5, [email protected] wrote:
> >
> > Please keep in mind that tup will pass a rather clean environment to
> its subprocesses. Maybe emacs misses something in its environment. You can
> force tup to pass select variables with the "export" directive.
> >
> > Kind regards, Bernhard.
> >
> >
> > On 18 June 2015 15:52:38 CEST, Gavin Cannizzaro <[email protected]
> <javascript:>> wrote:
> >
> > Further research shows that *all* commands (that I could think
> to try) return status 125 when called by emacs call-process via Tup. I'm
> assuming this has something to do with the fuse mount.
> >
> > Does anyone know what status 125 means? I haven't determined
> whether it's coming from the processes themselves, or from emacs, or fuse.
> >
> > Also, is there any way that I can debug this while the mount is
> active? By the time Tup is finished, the paths reported by commands no
> longer exist.
> >
> > Thanks,
> > Gavin
> >
> > --
> > --
> > tup-users mailing list
> > email: [email protected] <javascript:>
> > unsubscribe: [email protected] <javascript:>
> > 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] <javascript:> <mailto:
> [email protected] <javascript:>>.
> > For more options, visit https://groups.google.com/d/optout.
>
--
--
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/d/optout.
