The --lockfd option of runscript cannot be found in its manpage. Docuementation of OpenRC has no mention of how the overall lock/unlock works. Reproducible: Always
I looked up this option, and it appears to be an internal option users should not be attempting to use. I'm not sure it belongs on the man page, but I can add something like (internal use only) to the option description in runscript.
(In reply to William Hubbs from comment #1) > I looked up this option, and it appears to be an internal option users > should not be attempting to use. > I'm not sure it belongs on the man page, but I can add something like > (internal use only) to the option description in runscript. This problem belongs to porting on Debian where not only #!runscript based init files should work, and it appears that init scripts should support this option. So some description should be added.
(In reply to Alexander Vershilov from comment #2) > (In reply to William Hubbs from comment #1) > > I looked up this option, and it appears to be an internal option users > > should not be attempting to use. > > I'm not sure it belongs on the man page, but I can add something like > > (internal use only) to the option description in runscript. > > This problem belongs to porting on Debian where not only #!runscript based > init files should work, and it appears that init scripts should support this > option. > So some description should be added. If the Debian port is not using #!/sbin/runscript to run their init scripts,, they aren't using several features that are part of OpenRC, because these features are handled inside the runscript binary and runscript.sh. Specifically, they are missing /etc/conf.d/* handling, dependency handling and *_pre/post handling, among other things. Also, why do you say it appears that init scripts should support this option?
(In reply to William Hubbs from comment #3) > If the Debian port is not using #!/sbin/runscript to run their init > scripts,, they aren't using several features that are part of OpenRC, > because these features are handled inside the runscript binary and > runscript.sh. Specifically, they are missing /etc/conf.d/* handling, > dependency handling and *_pre/post handling, among other things. William, I understand your concern. Don't worry. We are doing a hack to let runscript to handle the init scripts without imposing a shebang change. Every Debian init script sources /lib/lsb/init-functions in the beginning, in which we hook into an exec of runscript: case $0 in *runscript.sh ) ;; * ) exec /sbin/runscript $0 "$@" ;; esac > Also, why do you say it appears that init scripts should support this option? I said "runscript" the binary, not initscripts, as you can see in git HEAD, $ grep -n -A5 -B5 lockfd -r . -- ./src/rc/runscript.c-1103- { "debug", 0, NULL, 'd'}, ./src/rc/runscript.c-1104- { "dry-run", 0, NULL, 'Z'}, ./src/rc/runscript.c-1105- { "ifstarted", 0, NULL, 's'}, ./src/rc/runscript.c-1106- { "ifstopped", 0, NULL, 'S'}, ./src/rc/runscript.c-1107- { "nodeps", 0, NULL, 'D'}, ./src/rc/runscript.c:1108: { "lockfd", 1, NULL, 'l'}, ./src/rc/runscript.c-1109- longopts_COMMON ./src/rc/runscript.c-1110-}; ./src/rc/runscript.c-1111-static const char *const longopts_help[] = { ./src/rc/runscript.c-1112- "set xtrace when running the script", ./src/rc/runscript.c-1113- "show what would be done", -- ./src/rc/rc-misc.c-299- /* Safe to run now, to support scripts without runscript shebang ./src/rc/rc-misc.c-300- we need to make a check first. */ ./src/rc/rc-misc.c-301- fsvc = fopen(file,"r"); ./src/rc/rc-misc.c-302- fgets(bsvc, sizeof(bsvc), fsvc); ./src/rc/rc-misc.c-303- if (strstr(bsvc, "runscript")) { ./src/rc/rc-misc.c:304: execl(file, file, "--lockfd", sfd, arg, (char *) NULL); ./src/rc/rc-misc.c-305- fprintf(stderr, "unable to exec `%s': %s\n", ./src/rc/rc-misc.c-306- file, strerror(errno)); ./src/rc/rc-misc.c-307- } else { ./src/rc/rc-misc.c-308- execl(file, file, arg, (char *) NULL); ./src/rc/rc-misc.c-309- }
(In reply to Benda Xu from comment #4) > (In reply to William Hubbs from comment #3) > > > If the Debian port is not using #!/sbin/runscript to run their init > > scripts,, they aren't using several features that are part of OpenRC, > > because these features are handled inside the runscript binary and > > runscript.sh. Specifically, they are missing /etc/conf.d/* handling, > > dependency handling and *_pre/post handling, among other things. > > William, I understand your concern. Don't worry. We are doing a hack to let > runscript to handle the init scripts without imposing a shebang change. > > Every Debian init script sources /lib/lsb/init-functions in the beginning, > in which we hook into an exec of runscript: > > case $0 in > *runscript.sh ) > ;; > * ) > exec /sbin/runscript $0 "$@" > ;; > esac I want to talk to you more about this, and how the port works, but that shouldn't be on this bug. > > Also, why do you say it appears that init scripts should support this option? > > I said "runscript" the binary, not initscripts, as you can see in git HEAD, Ok, sorry I misunderstood you. I ran your grep and do not see all of what you refer to on the master branch in our main repository, which is git://github.com/OpenRc/openrc.git. The URL I have for your repository, http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git shows that it is a full year behind OpenRC development. If you want your work integrated into OpenRC,Can you please update your repository and rebase your branches on current master? (again, this isn't really a topic for this bug though). Yes, runscript does support a --lockfd option, but it seems to be internal use only. Here is the explanation I got from the original author: " The idea is that we obtain an exclusive filesystem lock for the process based on the service name. This lock is released once the process dies or unlocked. Now, if a child process needs to know the fd so it can unlock it it needs to be passed to it. So if /sbin/rc starts service foo, it first obtains a lock fd and then passes it to the service using the --lockfd directive. It's passed like that as /sbin/rc could equally be a shell script. " All I could really add to the man page would be something about it being the file descriptor of the exclusive lock from rc, for internal use only.
(In reply to William Hubbs from comment #5) > (In reply to Benda Xu from comment #4) > > Ok, sorry I misunderstood you. > > I ran your grep and do not see all of what you refer to on the master branch > in our main repository, which is git://github.com/OpenRc/openrc.git. Excuse me... Are you sure? $ git clone git://github.com/OpenRC/openrc.git Cloning into 'openrc'... remote: Counting objects: 15292, done. remote: Compressing objects: 100% (6778/6778), done. remote: Total 15292 (delta 8526), reused 15145 (delta 8382) Receiving objects: 100% (15292/15292), 5.33 MiB | 537 KiB/s, done. Resolving deltas: 100% (8526/8526), done. $ grep -n -A5 -B5 lockfd -r openrc openrc/src/rc/rc-misc.c-294- openrc/src/rc/rc-misc.c-295- /* Unmask signals */ openrc/src/rc/rc-misc.c-296- sigprocmask(SIG_SETMASK, &old, NULL); openrc/src/rc/rc-misc.c-297- openrc/src/rc/rc-misc.c-298- /* Safe to run now */ openrc/src/rc/rc-misc.c:299: execl(file, file, "--lockfd", sfd, arg, (char *) NULL); openrc/src/rc/rc-misc.c-300- fprintf(stderr, "unable to exec `%s': %s\n", openrc/src/rc/rc-misc.c-301- file, strerror(errno)); openrc/src/rc/rc-misc.c-302- svc_unlock(basename_c(service), fd); openrc/src/rc/rc-misc.c-303- _exit(EXIT_FAILURE); openrc/src/rc/rc-misc.c-304- } -- openrc/src/rc/runscript.c-1103- { "debug", 0, NULL, 'd'}, openrc/src/rc/runscript.c-1104- { "dry-run", 0, NULL, 'Z'}, openrc/src/rc/runscript.c-1105- { "ifstarted", 0, NULL, 's'}, openrc/src/rc/runscript.c-1106- { "ifstopped", 0, NULL, 'S'}, openrc/src/rc/runscript.c-1107- { "nodeps", 0, NULL, 'D'}, openrc/src/rc/runscript.c:1108: { "lockfd", 1, NULL, 'l'}, openrc/src/rc/runscript.c-1109- longopts_COMMON openrc/src/rc/runscript.c-1110-}; openrc/src/rc/runscript.c-1111-static const char *const longopts_help[] = { openrc/src/rc/runscript.c-1112- "set xtrace when running the script", openrc/src/rc/runscript.c-1113- "show what would be done", > The URL I have for your repository, > http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git shows that it is a full > year behind OpenRC development. > > If you want your work integrated into OpenRC,Can you please update your > repository and rebase your branches on current master? > (again, this isn't really a topic for this bug though). Sorry for the confusion. The repo http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git is made desperate by http://anonscm.debian.org/gitweb/?p=collab-maint/openrc.git, on which we are planning to upgrade to OpenRC-0.12. > Yes, runscript does support a --lockfd option, but it seems to be internal > use only. Here is the explanation I got from the original author: > > " > The idea is that we obtain an exclusive filesystem lock for the process > based on the service name. > This lock is released once the process dies or unlocked. > > Now, if a child process needs to know the fd so it can unlock it it > needs to be passed to it. > So if /sbin/rc starts service foo, it first obtains a lock fd and then > passes it to the service using the --lockfd directive. > It's passed like that as /sbin/rc could equally be a shell script. > " > > All I could really add to the man page would be something about it being the > file descriptor of the exclusive lock from rc, for internal use only. Yes, that would be helpful. Thanks. I am wondering how to accept that lock fd as a plain sh script (instead of runscript) and unlock it from within. If that is unnatural, I'd like to find a clean way to completely disable lock fd mechanism. Adding a build option would be helpful, too. The parallel boot is not supported officially anyway, which is the reason lockfd existed originally.
Hi, William, this is for internal use only and should not be called explicitly. The Debian port is circumvented by calling /sbin/openrc-run <script>. Close as wontfix, thanks.
