runscript parses symlinks whose targets start with ./ incorrectly: root@l:/etc/init.d # rm net.eth0 root@l:/etc/init.d # ln -s ./net.lo net.eth0 root@l:/etc/init.d # /etc/init.d/net.eth0 start * WARNING: . is already starting root@l:/etc/init.d # /etc/init.d/net.eth0 status /lib/rc/sh/runscript.sh: line 13: .: /etc/init.d/../conf.d/.: is a directory * .: error loading /etc/init.d/../conf.d/. root@l:/etc/init.d # /etc/init.d/net.eth0 zap * Manually resetting . to stopped state * rc_service_mark: Is a directory root@l:/etc/init.d # rm net.eth0 root@l:/etc/init.d # ln -s net.lo net.eth0 root@l:/etc/init.d # /etc/init.d/net.eth0 zap * Manually resetting net.eth0 to stopped state root@l:/etc/init.d # /etc/init.d/net.eth0 start * Caching service dependencies ... * [ ok ] * Bringing up interface eth0 * dhcp ... The problem is that the dirname() call at runscript.c:1136 modifies lnk, so an incorrect name is returned by the basename() call at runscript.c:1140.
*** This bug has been marked as a duplicate of bug 350910 ***
*** Bug 366819 has been marked as a duplicate of this bug. ***
I do not see this as a duplicate of #350910. Basically, if a symbolic link links to something in the current directory, we should be able to resolve that, but it doesn't do anything about the other issue.
That's related to the other bug and to my patch. It should be fixed in git already. Symlink handling in general was/is? broken, both bugs are related to the same part of code.
Created attachment 280657 [details] 0001-fix-handling-of-symbolic-links-in-init.d-directory.patch All, I've thought about this quite a bit and I think the best way to go is to enforce the requirement from this comment in the openrc source code: /* We need to work out the real full path to our service. * This works fine, provided that we ONLY allow multiplexed services * to exist in the same directory as the master link. * Also, the master link as to be a real file in the init dir. */ The attached patch does this. What do you think about going this route?
Works for me.
All, after further discussion with robbat2 on irc yesterday, I believe that fixing bug #350910 will fix this as a side effect. It is technically not a duplicate, but it seems that marking this as a duplicate and moving all of the work to the other bug will be the easiest way to track this. *** This bug has been marked as a duplicate of bug 350910 ***
