/run & /var/run being a tmpfs
 

Hello,

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?

Hi,

I talked about that is this post.

The idea is to create the folder automatically when using "/etc/rc.d/rc.mydaemon start", so we have to adapt many SB.

If possible, try to compile with different path.

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.

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...

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 :D

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. :rolleyes: 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.

If there are services that are part of Slackware, please let me know which ones are affected so that I can fix them.

No, nothing from the core packages. No worries 🙂

/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.

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.

Any chance you're starting named with -u <some-non-root-user>?

yeah, I added it to the previous post :D
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.

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.