using rc.local

[jiml8]

A few months back, I constructed an rc.local file in order to handle some iptables things I wanted to happen on startup. When I enabled this file in /etc/rc.d my system promptly booted wrong, leaving a lot of stuff not running. I asked about it here, and someone pointed out that I had failed to put the shebang line into the file (duh!). Well, by the time that comment arrived, I had abandoned rc.local and was doing my iptables things using another more manual mechanism.

Fast forward to now. I have just removed my old SCSI subsystem and all 5 SCSI drives, replacing them with two SSDs. I now wish to tune the system for these SSDs on every startup - and I don't want to have to do it manually.

So, I dusted off my rc.local file and added the commands I wanted it to have, and put in the shebang line, and rebooted the system. The system booted wrong.

So I changed the shebang from !#/bin/sh to !#/bin/bash and tried again. Same thing. So, I disabled the rc.local file and booted the system...booted fine.

Here is the rc.local file. Can anyone here tell me how this should be configured in order to work properly? Or, perhaps, I need to report it as a bug?

Code: Select all

#!/bin/bash

# configure iptables to route internal NICs to internet
#iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 192.168.0.2
#iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -j SNAT --to-source
#192.168.0.2

#  configure for SSDs
echo deadline > /sys/block/sdc/queue/scheduler
echo deadline > /sys/block/sdd/queue/scheduler
echo 10 > /proc/sys/vm/swappiness

exit 0


[doktor5000]

So, I dusted off my rc.local file and added the commands I wanted it to have, and put in the shebang line, and rebooted the system. The system booted wrong.

So I changed the shebang from !#/bin/sh to !#/bin/bash and tried again. Same thing. So, I disabled the rc.local file and booted the system...booted fine.

How and at which step did the system boot wrong? Could you get the output from

Code: Select all

journalctl -ab

at that time?

[jiml8]

Boot seems to go wrong at the end. I don't seem to have a record of that particular boot in the journal; what I get starts with the subsequent (correct) boot when I use the journalctl command you gave. As I look into this, it appears that when I switched to SSDs and rebuilt the initrd, someone made a config change (probably dracut...don't know who else it would be) so the journal is being kept in RAM.

However, I can tell you that mysqld never starts, though it fails repeatedly to start. The plymouth boot screen never finishes, and although dm gets started, I never get an X display. I do get my consoles, and when I log in as root at a console and manually kill the plymouth boot screen, then I am able to restart dm and get an X display. I then can also manually start mysqld and have a working system.

But after X starts, my console screens vanish and are not to be seen again until a reboot. Thus, when something goes wrong with my desktop, I can't kill and restart from this system, though I can ssh in to do those things.

Now, I still run syslog, and although journal seems to be in RAM, /var/log/messages is still there. When I dig into it, I find this, which looks like the only possibly relevant failure:

Code: Select all

Oct 23 21:47:56 dadsbox systemd[1]: Starting Multi-User System.
Oct 23 21:47:56 dadsbox systemd[1]: Reached target Multi-User System.
Oct 23 21:47:56 dadsbox systemd[1]: Starting Graphical Interface.
Oct 23 21:47:56 dadsbox systemd[1]: Reached target Graphical Interface.
Oct 23 21:47:56 dadsbox systemd[1]: Starting Stop Read-Ahead Data Collection 10s After Completed Startu
p.
Oct 23 21:47:56 dadsbox systemd[1]: Started Stop Read-Ahead Data Collection 10s After Completed Startup
.
Oct 23 21:47:56 dadsbox systemd[1]: Starting Update UTMP about System Runlevel Changes...
Oct 23 21:47:56 dadsbox systemd[1]: Started Update UTMP about System Runlevel Changes.
Oct 23 21:48:26 dadsbox systemd[1]: Starting Stop Read-Ahead Data Collection...
Oct 23 21:48:26 dadsbox systemd[1]: Started Stop Read-Ahead Data Collection.
Oct 23 21:48:28 dadsbox systemd[1]: Starting Getty on tty2...
Oct 23 21:48:28 dadsbox systemd[1]: Started Getty on tty2.
Oct 23 21:48:34 dadsbox systemd[1]: Job dev-disk-by\x2duuid-0aa170b1\x2dda4f\x2d4b35\x2dba34\x2d770e28a
4381b.device/start timed out.
Oct 23 21:48:34 dadsbox systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-0aa170b1\x2dda4f\x
2d4b35\x2dba34\x2d770e28a4381b.device.
Oct 23 21:48:34 dadsbox systemd[1]: Dependency failed for /mnt/NAS.
Oct 23 21:48:34 dadsbox systemd[1]: Dependency failed for File System Check on /dev/disk/by-uuid/0aa170
b1-da4f-4b35-ba34-770e28a4381b.
Oct 23 21:48:34 dadsbox systemd[1]: Startup finished in 13.266s (kernel) + 1min 30.081s (userspace) = 1
min 43.348s.
Oct 23 21:48:35 dadsbox acpid: client 1279[0:0] has disconnected
Oct 23 21:48:35 dadsbox acpid: client 1279[0:0] has disconnected
Oct 23 21:48:38 dadsbox systemd[1]: Starting user-0.slice.
Oct 23 21:48:38 dadsbox systemd[1]: Created slice user-0.slice.
Oct 23 21:48:38 dadsbox systemd[1]: Starting User Manager for 0...
Oct 23 21:48:38 dadsbox systemd[1]: Starting Session c2 of user root.
Oct 23 21:48:38 dadsbox systemd[1]: Started Session c2 of user root.
Oct 23 21:48:38 dadsbox systemd-logind[1154]: New session c2 of user root.
Oct 23 21:48:38 dadsbox systemd[9855]: Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No such file or directory
Oct 23 21:48:38 dadsbox systemd[9855]: Starting Default.
Oct 23 21:48:38 dadsbox systemd[9855]: Reached target Default.
Oct 23 21:48:38 dadsbox systemd[9855]: Startup finished in 10ms.
Oct 23 21:48:38 dadsbox systemd[1]: Started User Manager for 0.
Oct 23 21:48:40 dadsbox acpid: client connected from 1279[0:0]
Oct 23 21:48:40 dadsbox acpid: 1 client rule loaded
Oct 23 21:48:40 dadsbox acpid: client connected from 1279[0:0]
Oct 23 21:48:40 dadsbox acpid: 1 client rule loaded
Oct 23 21:48:49 dadsbox acpid: client 1279[0:0] has disconnected
Oct 23 21:48:49 dadsbox acpid: client 1279[0:0] has disconnected
Oct 23 21:48:54 dadsbox acpid: client connected from 1279[0:0]
Oct 23 21:48:54 dadsbox acpid: 1 client rule loaded
Oct 23 21:48:54 dadsbox acpid: client connected from 1279[0:0]
Oct 23 21:48:54 dadsbox acpid: 1 client rule loaded
Oct 23 21:49:29 dadsbox acpid: client 1279[0:0] has disconnected
Oct 23 21:49:34 dadsbox acpid: client 1279[0:0] has disconnected
Oct 23 21:50:26 dadsbox acpid: client connected from 1279[0:0]
Oct 23 21:50:26 dadsbox acpid: 1 client rule loaded
Oct 23 21:50:27 dadsbox acpid: client connected from 1279[0:0]
Oct 23 21:50:27 dadsbox acpid: 1 client rule loaded
Oct 23 21:50:34 dadsbox acpid: client 1279[0:0] has disconnected
Oct 23 21:50:34 dadsbox acpid: client 1279[0:0] has disconnected
Oct 23 21:51:52 dadsbox systemd[1]: Stopping Display Manager...
Oct 23 21:51:52 dadsbox mgaapplet[3738]: Received SIGHUP (probably an upgrade has finished), restarting applet.
Oct 23 21:51:53 dadsbox systemd[1]: Starting Display Manager...
Oct 23 21:51:53 dadsbox systemd[1]: Started Display Manager.


Note the dbus failure. Also, at the end of this segment, mgaapplet received SIGHUP. That would be me killing the plymouth login display (note my login a minute earlier on console 2). Also note that I stop/start dm.

The iscsi share failures you see here are not relevant; there was an error in a udev rule that I did not detect and did not worry about...I have been starting that share manually after logging in rather than debug the known problem in automatic detection/mounting. I did just correct that rule, since I spotted the error in the journal while digging into this particular rc.local issue. So maybe next time it will start correctly on boot. We'll see, and I don't care that much.

[jiml8]

I infer from the lack of response that no one sees anything wrong with my rc.local file. Hence, this likely is a bug in how the init scripts are handled by systemd.

Rather than fool with it, I guess I will construct a service and place the script into /etc/rc.d/init.d with appropriate symlinks for runlevels and start/stop/restart functionality, then let systemd deal with it that way. It should do that correctly, though given how seldom I reboot it might take a long time to debug any issues with it.

[martinw]

Why not create a systemd service to do the job? It's not that hard. Here's how I disable wake-up-on-lan on my laptop:

1. Create the file /lib/systemd/system/wol-disable.service containing:

Code: Select all

[Unit]
Description=Disable wake-up-on-lan
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "ethtool -s eno1 wol d"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target


2. Execute the following commands (as root):

Code: Select all

systemctl enable wol-disable.service
systemctl start  wol-disable.service


[bittwister]

Can anyone here tell me how this should be configured in order to work properly? Or, perhaps, I need to report it as a bug?

Code: Select all

#!/bin/bash

# configure iptables to route internal NICs to internet
#iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 192.168.0.2
#iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -j SNAT --to-source
#192.168.0.2

#  configure for SSDs
echo deadline > /sys/block/sdc/queue/scheduler
echo deadline > /sys/block/sdd/queue/scheduler
echo 10 > /proc/sys/vm/swappiness

exit 0


Off hand I can not see any problems but I do not have access to SSD devices.
What I can suggest is try putting your /sys/ configurations in a /etc/sysctl.d/ conf file.

Example snippets from /etc/sysctl.d/my__sysctl.conf
# Enabling core dump PID appending and set core location and name
kernel.core_uses_pid = 1
kernel.core_pattern = "/var/tmp/%e_%p_%s.core"
vm.swappiness = 10
net.ipv4.conf.all.log_martians = 1
net.core.rmem_max = 1048576

You can then use sysctl to load/verify your file before rebooting.


I will also echo martinw advice. Use a custom service file if the activity can not go into a configuration file. That way a "systemctl status whatever will can save some hunting around in the journal.

[ITA84]

I'm not on Mageia right now, but in Fedora the rc.local compatibility service now seems to require start/stop argument parsing in the script. Will check later, but for your specific issue bittwister's solution is definitely preferable.

EDIT: yes, it's the same in Mageia, although I don't know if not having argument parsing matters.