SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If there are services that are part of Slackware, please let me know which ones are affected so that I can fix them.
I've been sneaking fixes for those in for a couple of years now in preparation for when you'd finally give in on the /var/run --> /run bindage, so there shouldn't be any ;-)
It doesn't do just as well. I did a lot of initial testing on this starting several years ago, and while it was indeed rare, there were cases where things didn't like the symlink being there. One of them something in the core distribution, but I cannot for the life of me recall what it was.
That sounds somewhat apocryphal, and I cannot see how having /var/run as a symlink to /run (where tmpfs is to be mounted on /run), could cause problems since the symlink is in the absence of explicit deletion permanently on the file system. If a bind mount works (which would be effected on every boot) where a symlink doesn't it may possibly evidence a timing bug in slackware's init scripts but that sounds somewhat improbable. In any event, other distributions I have come across have /var/run as a symlink to /run and as it happens those using systemd are required to do so. (That is an aside: please let's not start a systemd thread.)
In other distros /var/run has been sym linked to /run for many years. This is standard practice among most distros. If there are any issues in Slackware then users need not look far to see how others resolved the problems.
I've been sym linking on Slackware for many years. While I don't run the full array of possible daemons or services, I never once ran into any issue.
After a bit of research, it was libnih and cgmanager that didn't play nicely with the symlink. The reason other distros don't have the problem is that they're not using those - they're using systemd instead (or they patched those to use /run directly instead of /var/run, which was not an option at all at the time for us).
Any chance you're starting named with -u <some-non-root-user>?
Why are the permissions of /var/named now changed recursively? I start named with -u named -t /var/named. There are a lot files below my /var/named directories that musn't belong to the named user. Let's see if I can chroot to another directory. But the Slackware init scripts are becoming as complex and at the same time inflexible as the old Debian init scripts.
Why are the permissions of /var/named now changed recursively? I start named with -u named -t /var/named. There are a lot files below my /var/named directories that musn't belong to the named user. Let's see if I can chroot to another directory. [...]
Sorry for the above comment. Chowning /var/named to the named user is fine. Only the recursive bit would have been a problem. I wasn't sure whether /var/named is hardcoded somewhere. It isn't. I use the directory /var/named-chroot now in my setup and this works without problems.
Sorry for the above comment. Chowning /var/named to the named user is fine. Only the recursive bit would have been a problem. I wasn't sure whether /var/named is hardcoded somewhere. It isn't. I use the directory /var/named-chroot now in my setup and this works without problems.
No need to be sorry - I still think you were correct that the rc.bind script had no business messing with the file ownerships in /var/named like it was. If named is going to be picky about ownership and not start (when it's been configured in a non-standard and not recommended way), let the admin figure out how to fix it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.