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]
> 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]
> <mailto:[email protected]>.
> 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.
