Hello, I just installed baselayout-2.0.1-r1 and openrc-0.6.8. After merging all config files and rebooting, I get an error for my own firewall-init-script. All my scripts are managed in a SVN repo, which is located in /usr/local/svn-repo on all my systems. Now I symlinked /usr/local/svn-repo/scripts/sbin/firewall.init to /etc/init.d/firewall. With baselayout-1, I had no problems using this script just like any other init-script. But trying to start it with baselayout-2 returns an error message: /lib64/rc/sh/runscript.sh: line 171: .: /usr/local/svn-repo/scripts/sbin: is a directory. The script also doesn't start. Deleting the symlink and simply copying the script to /etc/init.d/ makes it work without any problems. So the problem occurs only when the script is symlinked. Reproducible: Always Steps to Reproduce:
post an actual file that can be downloaded, and then post the actual commands you're using to link in things and then execute (and show the actual output) moving a random init.d file out of /etc/init.d/ and symlinking it back seems to work fine for me.
OK, here wo go. First some more information on my directory structure: my scripts are in /usr/local/svn-repo/scripts/sbin/, the filename is firewall.init. So the full path of the particular script is /usr/local/svn-repo/scripts/sbin/firewall.init. Additionally, /usr/local/sbin is a symlink to svn-repo/scripts/sbin, so I can run scripts in this directory also as root from command line. cd /usr/local ls -lh [...] sbin -> svn-repo/scripts/sbin [...] When I first installed this init-script, I made the following link: cd /etc/init.d ln -s /usr/local/sbin/firewall.init firewall With baselayout-1, I could now use /etc/init.d/firewall just like any other init-script. With baselayout-2, I did some more tests. This is what does work: cd /etc/init.d/ rm firewall cp -a /usr/local/sbin/firewall.init firewall => works rm firewall ln -s /usr/local/svn-repo/scripts/sbin/firewall.init . => works (as firewall.init) This does NOT work: cd /etc/init.d/ rm firewall ln -s /usr/local/sbin/firewall.init firewall => does not work rm firewall ln -s /usr/local/sbin/firewall.init . => going over the /usr/local/sbin/ symlink does not work at all rm firewall ln -s /usr/local/svn-repo/scripts/sbin/firewall.init firewall => changing the filename does not work either I'll attach a simplified version of firewall.init, so you could also test it.
Created attachment 259462 [details] My dynamic rule generation script This script generates three files in /tmp, and generates from these files iptables-rules. When the script is stopped, nothing gets in and out over the net. If the script is started, but the three files are empty, traffic can go out and replies can get in. If subnets and ports are added to the files, a /etc/init.d/firewall reload automatically generates rules to allow incoming traffic for this port for this subnet.
Small update: today I tested openrc-0.7.0 which gave me the same error messages and the same behaviour like openrc-0.6.8.
I reproduced this as well. The problem happens when the basename of the init script itself and the basename of the symlink linking to it are not the same.
(In reply to comment #5) > The problem happens when the basename of the init script itself and the > basename of the symlink linking to it are not the same. > As you can see from my tests in comment #2, the problem also occurs when the path "goes over" a symlink. ln -s /usr/local/svn-repo/scripts/sbin/firewall.init . works, while ln -s /usr/local/sbin/firewall.init . does not work. As already mentioned, /usr/local/sbin is a symlink on my systems to /usr/local/svn-repo/scripts/sbin
I just found the following text in the bugs section of the runscript man page: " Because of the way we load our configuration files and the need to handle more than one service directory, you can only use symlinks in service directories to other services in the same directory. You cannot symlink to a service in a different directory even if it is another service directory." This appears to be a known issue. What does everyone else think?
if we're going to ban it, we should ban it. i.e. have runscript detect that the symlink contains path components and abort immediately.
*** Bug 366617 has been marked as a duplicate of this bug. ***
After the recent baselayout2/openrc stabilization I ran into this problem, too. If this behaviour is intended, it needs a better output than it currently has and which looks like a bug. Either way at least for me this is a major regression over the old versions. Managing/Versioning your custom scripts outside of /etc/init.d/ isn't an exotic requirement, I think.
I have the same issue and really want to someone fix this regression or suggest alternative way
*** Bug 366819 has been marked as a duplicate of this bug. ***
*** Bug 365955 has been marked as a duplicate of this bug. ***
I just ran into this yesterday. My company uses some custom init scripts where multiple different links in /etc/init.d symlink to the one script in an external directory (and perform different actions based on the SVCNAME). To work around this I have to temporarily make actual copies of the script in /etc/init.d. I could really use a solution to this one.
Created attachment 273833 [details, diff] Patch to fix dirname() call in runscript.c The dirname() call at runscript.c:1136 modifies lnk, so an incorrect name is returned by the basename() call at runscript.c:1140. The patch saves lnk before the call.
(In reply to comment #7) > I just found the following text in the bugs section of the runscript man page: > > " Because of the way we load our configuration files and the need to handle > more than one service directory, you can only use symlinks in service > directories to other services in the same directory. You cannot symlink > to a service in a different directory even if it is another service > directory." > > This appears to be a known issue. What does everyone else think? The issue is this /etc/init.d net.lo net.eth0 -> net.lo /etc/conf.d net /usr/local/etc/init.d net.lo net.eth1 -> net.lo /usr/local/conf.d net A perfectly valid setup, which works 100%. Now add net.eth2 in /etc/init.d which links to /usr/local/etc/init.d/net.lo Which config file is it supposed to use? The last I looked at this there may have been other complications, but that is the meaning behind that man page entry.
(In reply to comment #16) > The issue is this > /etc/init.d > net.lo > net.eth0 -> net.lo > /etc/conf.d > net > /usr/local/etc/init.d > net.lo > net.eth1 -> net.lo > /usr/local/conf.d You mean /usr/local/etc/conf.d here right?
Then perhaps 366819 and 365955 are not duplicates.
(In reply to comment #17) > (In reply to comment #16) > > The issue is this > > /etc/init.d > > net.lo > > net.eth0 -> net.lo > > /etc/conf.d > > net > > /usr/local/etc/init.d > > net.lo > > net.eth1 -> net.lo > > /usr/local/conf.d > > You mean /usr/local/etc/conf.d here right? Right
(In reply to comment #18) > Then perhaps 366819 and 365955 are not duplicates. I think that they are, but different entry points to the same problem. The easiest fix for those to is to remove ./ if it starts with ./ The bug report here though is more complex and sadly fits into my above scenario. I didn't come up with a reasonable fix, but I don't recall it erroring like it does now either. Now, you may ask *why* it's needed. And the reason is thus - to separate base system scripts from package scripts entirely which is how BSD portage equivalents work. package system borked? Want to change from pkgsrc to ports or portage? Just rm -rf /usr/pkg or /usr/local depending on setup and you're good to go.
I see your point about the bug in this report and you're right that the fix for the others is trivial, so I don't want to belabor the point. Still, the dirname(3) manage says: Both dirname() and basename() may modify the contents of path, so copies should be passed to these functions. It would seem that these lines are a bug because, at the very least, they depend on undocumented behavior. 1136 dir = dirname(lnk); 1137 if (strcmp(dir, save) == 0) 1138 file = basename_c(argv[1]); 1139 else 1140 file = basename_c(lnk);
Created attachment 281179 [details] 0001-do-not-treat-symbolic-links-specially-in-init.d.patch All, in my testing, this patch seems to fix the issue. It allows links in init.d directories to point anywhere, but it requires that for an init.d directory there is a conf.d directory at the same level in the tree to hold configuration files that match the services in the init.d directory. I need comments and testing for this fix. In particular, does it still allow BSDs to work properly?
Created attachment 281201 [details] 0001-Improve-processing-of-conf.d-files.patch All, after discussion with robbat2, I came up with this patch. Now besides checking in the relative ../conf.d directory for configuration files, we also check @sysconfdir@/conf.d. I have tested this patch and it works here, so if there are no objections I will commit it to the tree. Can anyone say if this patch is OK for BSDs as well?
This patch, including an update to the man page, has been implemented in commit 0c8bea2.
All, we need to re-visit this bug. The commit I mentioned that seemed to fix the issue causes the regression in bug #392457. Also, the RC_SERVICE environment variable is now set incorrectly, so I don't know of what other possible regressions it might be causing. I would like to revert this commit asap and work out another fix.
*** Bug 411583 has been marked as a duplicate of this bug. ***
It seems to me that you could just use: service = realpath(argv[1], NULL); // from #392457 comment 3 applet = basename_c(argv[1]); ..as the applet name is always present in the argument, even if run from within /etc/init.d, eg as ./net.eth0 Sorry if I'm missing something obvious. WRT to the shell patch, wouldn't: if [ -f "${RC_SERVICE%/*}/../conf.d" ]; then loadconfig "${RC_SERVICE%/*}/../conf.d" else loadconfig "@SYSCONFDIR@/conf.d" fi ..be more what the user is after?
> if [ -f "${RC_SERVICE%/*}/../conf.d" ]; then Doh, that should be -d not -f ofc. (I just think it's a bit safer, but might not be what you want.) Sorry for noise.
*** Bug 425656 has been marked as a duplicate of this bug. ***
*** Bug 470854 has been marked as a duplicate of this bug. ***
