[quote=418663:@Alex Bombay]Update: Has nothing to do with Debian. Starting the process with “./MyApp” will change the CWD to root after Daemonization, however, starting the app with “/Path/To/MyApp” works correctly. There must have been some change between 2013r3 and 2014r4 that affected the way apps daemonize. Grateful if we could get this fixed, working on a bug report.
Thanks!
Basiclly everything below is just extra information at this point.
Here is an strace of the process right after it the Daemonize call:
+++ exited with 0 +++
strace: Process 18122 attached
open("/dev/null", O_RDWR) = 4 <0.000018>
open("/proc/self/maps", O_RDONLY|O_CLOEXEC) = -1 EMFILE (Too many open files) <0.000006>
write(2, "Runtime Error\
Please report what caused this error along with the information below.\
Universal/CrawlStack.cpp: 64\
Failure Condition: rc == 0\
pthread_getattr_np: 24\
", 164) = 164 <0.000006>
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=18122, si_uid=1000} ---
+++ killed by SIGABRT +++
I increased the amount of max open files and I got this:
pipe([4, 5]) = 0 <0.000010>
vfork(strace: Process 22829 attached
<unfinished ...>
[pid 22829] close(4) = 0 <0.000005>
[pid 22829] dup2(5, 1) = 1 <0.000004>
[pid 22829] dup2(1, 2) = 2 <0.000006>
[pid 22829] close(5) = 0 <0.000005>
[pid 22829] getrlimit(RLIMIT_NOFILE, {rlim_cur=40000, rlim_max=100000}) = 0 <0.000005>
[pid 22829] close(3) = 0 <0.000005>
[pid 22829] close(4) = -1 EBADF (Bad file descriptor) <0.000005>
[pid 22829] close(5) = -1 EBADF (Bad file descriptor) <0.000004>
... (continues)
[pid 22829] close(39997) = -1 EBADF (Bad file descriptor) <0.000005>
[pid 22829] close(39998) = -1 EBADF (Bad file descriptor) <0.000004>
[pid 22829] close(39999) = -1 EBADF (Bad file descriptor) <0.000004>
... (some other stuff) ...
[pid 22829] mprotect(0x56127c785000, 4096, PROT_READ) = 0 <0.000008>
[pid 22829] mprotect(0x7f6575666000, 4096, PROT_READ) = 0 <0.000017>
[pid 22829] munmap(0x7f657565b000, 28824) = 0 <0.000015>
[pid 22829] getrlimit(RLIMIT_NOFILE, {rlim_cur=40000, rlim_max=100000}) = 0 <0.000005>
[pid 22829] close(39999) = -1 EBADF (Bad file descriptor) <0.000004>
[pid 22829] close(39998) = -1 EBADF (Bad file descriptor) <0.000004>
[pid 22829] close(39997) = -1 EBADF (Bad file descriptor) <0.000004>
... (continues)
[pid 22829] close(5) = -1 EBADF (Bad file descriptor) <0.000004>
[pid 22829] close(4) = -1 EBADF (Bad file descriptor) <0.000004>
[pid 22829] close(3) = -1 EBADF (Bad file descriptor) <0.000004>
[pid 22829] brk(NULL) = 0x56127e5bf000 <0.000005>
[pid 22829] brk(0x56127e5e0000) = 0x56127e5e0000 <0.000007>
[pid 22829] getuid() = 1000 <0.000004>
[pid 22829] getgid() = 1000 <0.000004>
[pid 22829] geteuid() = 1000 <0.000004>
[pid 22829] getegid() = 1000 <0.000005>
... (some more stuff)
! (App.Daemonize) !
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fe37f688990) = 22830 <0.000177>
exit_group(0) = ?
+++ exited with 0 +++
strace: Process 22830 attached
set_robust_list(0x7fe37f6889a0, 24) = 0 <0.000005>
setsid() = 22830 <0.000009>
chdir("/") = 0 <0.000007>
open("/dev/null", O_RDWR) = 4 <0.000009>
After all this there are a bunch of lstat “ENOENT (No such file or directory)” errors and rt_sigprocmask calls
rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 <0.000006>
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 <0.000005>
rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 <0.000005>
rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], ~[KILL STOP RTMIN RT_1], 8) = 0 <0.000004>
rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 <0.000005>
[code]% time seconds usecs/call calls errors syscall
37.28 0.000334 0 161773 rt_sigprocmask
19.75 0.000177 0 67952 40457 lstat
12.50 0.000112 0 80076 79996 close[/code]
I am not quite sure what is going on with calling close on 40k files twice, but this bit right here “chdir(”/")" gives me the feeling that Xojo is attempting to change to the root directory when calling daemonize on debian systems. By symlinking the app in root “/” it woks without any problem.
Thanks for everyones help, hopefully we can get this resolved in one way or another.[/quote]
You didnt happen to try this with a newer Xojo version did you? Its possible that this was already fixed (assuming its a bug).