Who moved the rc.local ??

English Install/Boot/Login
1

Yet another hurdle in migrating my stuff from ubuntu to opensuse…
I would like to execute a command while booting into the system in order to remove some lock files that may be hanging around after a OS crash.
The commands are:

This section below cleans up any heyu files that may exist

after a server unclean shutdown.

if -e /var/lock/LCK…heyu.aux.ttyS1 ]
then
/bin/rm -f /var/lock/LCK…heyu.aux.ttyS1
fi
if -e /var/lock/LCK…heyu.engine.ttyS0 ]
then
/bin/rm -f /var/lock/LCK…heyu.engine.ttyS0
fi

I used the rc.local script file in Fedora/Ubuntu. AFAIK there is no rc.local equivalent file in openSuSe.
So what’s the correct way to do this? (opensuse 13.2)

Doing some googling uncovered some options but, arguments about where to put it resulted in no CLEAR answer.
/etc/rc.d/boot.local
after.local under openSUSE when booted in sysvinit
others???

Thanks for the help…wish there was some place to read this stuff…
J

2

On default 13.2 installation /var/lock is tmpfs and so is cleared automatically on every reboot.

3

Really?
Well, this has happened twice to me…OS crashed, I start my heyu application, it complains a lock file exists…I go to /var/lock/LCK…heyu.aux.ttyS1 and remove the file, and heyu is happy.

My install of 13.2 is new,‘out of the box’ with all the appropriate updates.
I don’t mean to be untrusting but I’ve seen it twice.
Thank you for your help…

4

Yes. Show output of “df -h /var/lock”.

5

jjh@linux:~> df -h /var/lock
Filesystem Size Used Avail Use% Mounted on
tmpfs 1008M 2.1M 1006M 1% /run

not sure what this is telling me tho.

6

Apart from lack of tags code? That /var/lock points to filesystem which is mounted on tmpfs - iow, it is contained entirely in RAM and content disappears when system shuts down (or reboots).

7

I issued the command as you stated and that is what I got. Tag codes? IDK what they are.
OK, so locks points to a volatile section in RAM that is created when booted. Your assertion is that since it is in RAM and volatile, it is recreated anew when the system boots. It could be that its state is saved periodically and the saved state is restored on boot (It is possible but IDK for sure that it is stateless). None the less, I cannot explain what I saw…

Just for grins, I think I’ll put the code in /etc/rc.d/after.local (when I opened boot.local, the description in the file said to install commands after system has finished first phase of booting…and since i cannot find documentation about what the phases are, I assume basic OS infrastructure is in place at that point)

how do I know if my version boots in the ‘old’ way (booted in sysvinit) or the ‘new’ way? (however it is referred…)???
/vent=on
I think it is ridiculous that I have to know this much of the OS in order to track down an issue/make something work…I wonder what participated the change over? From what I’ve read, the new approach is designed to make booting faster, and the boot order is somewhat non-deterministic - which seems like a bad idea…
/vent=off

Thanks for your help

8

Any tmpfs goes away on reboot or power off. It may be preserved with hibernate.
I find systemd much easier once you understand it. Yes you do have to learn something new :open_mouth:

https://wiki.archlinux.org/index.php/systemd

https://www.linux.com/learn/understanding-and-using-systemd

Boot processes are processed sequential if dependent but non-dependent process are done in parallel Yo can see this with the folowing


systemd-analyze
and
systemd-analyze critical-chain
and
systemd-analyze blame

code tags are the # sign in the forum editor tool bar it keeps pasted computer text from being reformatted and easier to read.

9

Actually, this (the original question) is not even related to the switch to systemd.

In (open)SUSE, /etc/rc.d/ was moved to /etc/init.d/ long (years) before that (though it still exists for compatibility reasons…)

# ls -ld /etc/rc.d

lrwxrwxrwx 1 root root 6  4. Nov 2014  /etc/rc.d -> init.d

(don’t get confused by the date, that’s just on my system here, init.d is used much longer…)

And I cannot even remember when rc.local was last used.

But, just putting your things into /etc/init.d/boot.local should work, although it shouldn’t be necessary at all as pointed out already…:wink:

10

Thanks for the helpful info - much appreciated.
I don’t mind learning new stuff…just a little frustration when something that seemed to be a ‘given’ for a number of years has changed.
I’ve lived through lots of changes- been doing dev work starting with Unix V6, V7, BDSV7, Slack, Deb, Ubuntu and circumstances forced me OpenSUSE…and that is just on the *nix side of life…

11

Thanks, I appreciate the insight.
J