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

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 ;-)

Re bind, easiest solution was to put this in /etc/default/named:
That's what we've done for a while on a couple of DNS servers here...

oh perfect! Thanks Robby!

Perfect! Thanks Pat! :)

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

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.

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.