Rc.local not executable

not sure where to put this, someone more powerful than me can move it if necessary.

First time RL installer, chose RL9 for a test server for a small, specific need, after a minimal install and installing the epel-release, "Development Tools, a “dnf update”, and a reboot, got the following error when installing pure-ftpd (successfully), thought I’d pass it along, as it just appears to be a simple 644 → 755 permissions issue that got overlooked:

/etc/rc.d/rc.local not marked executable, skipping

and this is what that file looks like:

-rw-r--r-- 1 root root ... /etc/rc.d/rc.local

with a simplified content of

touch /var/lock/subsys/local

so it looks like it should be 755 instead of 644
that’s what I know
I did see this message when installing a couple other rpms later, but don’t think those specifics are important.

Edit: visual formatting issues, finally got it right!


Not been overlooked, this is the norm. Pure-ftpd uses rc.local for systems without systemd. On Rocky 9 and indeed since RHEL/Centos7 it has used a service file provided by the rpm to start the server.

Thanks Tom.

guess i’m not understanding the answer.

you’re saying RL9 doesn’t use systemd, so PF is trying to use a different mechanism to start itself on startup, and that mechanism is “off” by default? or is it trying to use both mechanisms, and one is disabled? maybe you mean rc.local shouldn’t be executable because it’s no longer being used, and PF shouldn’t be trying to use it because it’s already using some other mechanism that does work?

my takeaway is that it’s a PF issue, and because it is starting up on reboot, it’s just an installation issue PF needs to clean up.



No Rocky 9 does use a systemd, which is why the installer skips using rc.local.

So systemd systems have an rc.local file for compatibly, but by default isn’t executable.

So I think the PF uses this check to determine if start is via rc.local (if rc.local is executable) or a systemd service file.

Regards Tom.

ah, so it’s not an error message, it just the installation reporting that it’s not going to use that mechanism.
thanks for the clarification and education!


What I REALLY don’t understand is the the USER Surprise that comes with running RHEL 9.0 (RL 9.0, ALMA Linux 9.0; et al) distros. ANY xyz.0 distro – especially a bug-for-bug-copy of RHEL 9.0 is going to be BUGGY. I have made it a point NOT to try any xyz.release, least I pull my hair out.

While I have some spare 1 TB HDD now installed in ocelot I’m not about to try RL 9 until it reaches 9.2. Mind you I have been away from these forums for awhile due to medical problems from a bike crash back on July 9. Indeed I just got RL 8.6 installed on my Corsair MP600 NVMe M.2 SSD wITHOUT ANY ERRORS just yesterday. HALLELUJAH!!! Just don’t ask me what I did, as I don’t know. While I have 2 other copies of 8.6 running, they are on HDD’s, not my NVMe 4th Gen. drive. Couple that to a ASUS motherboard that has an AMD Ryzen 9 5900X CPU and 64 GB of RAM. To say that it is FAST would be an understatement – when I did the install yesterday I was expecting it to take 30 minutes – assuming it did not blow up first half way through the install – my previous problem – instead the whole thing was DONE in 10-15 minutes!!! Nor has there been any slow down as I continue configuring the OS. Compared to the two copies of RL 8.6 I have running (one on an SSD and one on a HDD) the one I installed yesterday on the NVMe 4th Gen makes those two look pathetically SLOW!!!

You may see me more often assuming I am awake – I sleep a lot now.

There were no bugs here. Some surprises, but no bugs.

Yes, each major version of Enterprise Linux is different from all the previous. The way the system is configured and managed is different – changed and/or evolved (although some deem some design choices regressions).