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.
Speaking of a recent change in current,
are we sure that having /run and now also /var/run, because it's a bind mount, as tmpfs is fine?
I've already found issues with services that do not recreate a folder in /var/run at startup because they expect it to be permanent, and so they don't start.
Is it the services that should be fixed or the directory that should be made not a tmpfs?
just a suggestion: if you get in touch with the scripts maintainers and ask to adapt them to create the the directory (as-needed) at start they will be current-ready in no-time.
Quote:
Originally Posted by linuxxer
If possible, try to compile with different path.
IMHO there should be no need, because the stuff in /var/run/*/ if meant to be "volatile" in the first place so should be fine for it to disappear at reboot...
just a suggestion: if you get in touch with the scripts maintainers and ask to adapt them to create the the directory (as-needed) at start they will be current-ready in no-time.
Yes, I can also fix them myself once I find out what was there before and what permissions it had, considering that previous content of /var/run has been efficently wiped
Btw it seems that the "other system" has got a method to deal with this.
Btw it seems that the "other system" has got a method to deal with this.
Why use something simple like a mkdir in the sysinit script when you can come up with something really complicated instead. Typical freedesktop/Lennart solution.
Why use something simple like a mkdir in the sysinit script when you can come up with something really complicated instead. Typical freedesktop/Lennart solution.
Why set up a bind mount for /var/run in rc.S, when a symlink to the /run tmpfs would do just as well and require nothing in rc.S at all? Choices.
I've already found issues with services that do not recreate a folder in /var/run at startup because they expect it to be permanent, and so they don't start.
If there are services that are part of Slackware, please let me know which ones are affected so that I can fix them.
If there are services that are part of Slackware, please let me know which ones are affected so that I can fix them.
/var/run/named would need to be created, even if named seems to be working fine without it.
When it exists, the named.pid will be inside it, otherwise it's not present.
/var/run/named would need to be created, even if named seems to be working fine without it.
When it exists, the named.pid will be inside it, otherwise it's not present.
By default, the folder is automatically created by named, there is no need to change anything in rc.bind. I just tried to "rc.bind stop" then "rm -rf /var/run/named" then "rc.bind start". The folder is here with "named.pid" and "session.key" inside.
By default, the folder is automatically created by named, there is no need to change anything in rc.bind. I just tried to "rc.bind stop" then "rm -rf /var/run/named" then "rc.bind start". The folder is here with "named.pid" and "session.key" inside.
I can't confirm it. I have to create it manually after reboot otherwise it's not there.
Edit: but probably I realized why. I start named with "-u daemon" so probably it doesn't have permission to create the folder on its own. It's an old habit of not running named as root. So nevermind, it doesn't require a fix in the startup script.
Last edited by lonestar_italy; 02-17-2020 at 02:47 PM.
Reason: Addition
Any chance you're starting named with -u <some-non-root-user>?
yeah, I added it to the previous post
I'm following the old way of starting it with -u daemon.. it's still referred in rc.bind
Maybe it's good to add a note that if still using this method, recreating /var/run/named at boot is on the user.
Why set up a bind mount for /var/run in rc.S, when a symlink to the /run tmpfs would do just as well and require nothing in rc.S at all? Choices.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Typical freedesktop/Lennart solution.
