Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with daemonize and runsvdir on Android 7 #614

Closed
Neo-Oli opened this issue Dec 22, 2016 · 0 comments
Closed

Issue with daemonize and runsvdir on Android 7 #614

Neo-Oli opened this issue Dec 22, 2016 · 0 comments
Labels
bug report Something is not working properly information Informational post

Comments

@Neo-Oli
Copy link
Member

Neo-Oli commented Dec 22, 2016

On Android 7, When running the following daemonize command runsvdir will fail.
daemonize -l $PREFIX/var/run/runsvdir.lock -p $PREFIX/var/run/runsvdir.pid $PREFIX/bin/applets/runsvdir /data/data/com.termux/files/home/.sv

Checking the logs reveals the following problem:

$ daemonize -vo ~/output -e ~/error -l $PREFIX/var/run/runsvdir.lock -p $PREFIX/var/run/runsvdir.pid $PREFIX/bin/applets/runsvdir /data/data/com.termux/files/home/.sv
$ cat error
runsvdir: /data/data/com.termux/files/home/.sv: fatal: can't open current directory: Permission denied

After a lot of testing I finally figured out the problem: Everything daemonize executes is run from the / directory (that's why it needs absolute paths). Starting with Android 7 / no longer has read permissions.

$ ls /
ls: cannot open directory '/': Permission denied

runsvdir, for some reason, needs read access to the current working directory.

Workaround

Specifing the working directory for daemonize fixes the problem
daemonize -c $PREFIX -l $PREFIX/var/run/runsvdir.lock -p $PREFIX/var/run/runsvdir.pid $PREFIX/bin/applets/runsvdir /data/data/com.termux/files/home/.sv

Perhaps daemonize could be patched to set the default working directory to $PREFIX

@Neo-Oli Neo-Oli added bug report Something is not working properly information Informational post labels Dec 22, 2016
birros added a commit to birros/termux-services that referenced this issue Jun 7, 2020
Since an update, service-daemon refuses to start, it seems necessary to manually
specify the working directory of start-stop-daemon to avoid permission errors.

This issue seems to be related to this one:
termux/termux-packages#614
ghost pushed a commit to termux/termux-services that referenced this issue Jun 7, 2020
Since an update, service-daemon refuses to start, it seems necessary to manually
specify the working directory of start-stop-daemon to avoid permission errors.

This issue seems to be related to this one:
termux/termux-packages#614
@ghost ghost locked and limited conversation to collaborators Oct 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug report Something is not working properly information Informational post
Projects
None yet
Development

No branches or pull requests

1 participant