I have to run some scripts at the end of the boot process to establish various workarounds for bugs in systemd. In the days of System V, /etc/rc.d/rc.local would be the right place for this.
My research revealed several solutions with conflicting recommendations: (a) There is - also in Fedora - systemd-rc-local service. In the man file it is advised not to use it. A Fedora default installation also does not completely create the necessary directory structure. And if one wants to execute this service as far as possible at the end of the boot process, further adjustments are necessary.
(b) There is the DIY suggestion to create a service of one's own, and to place it as far as possible at the end of the system start.
(c) A suggestion is to insert in the root-crontab at the end @reboot systemctl start ….
The latter seems to be the most reliable solution at the moment.
Any recommendations and/or experiences?
On Mon, 18 Jul 2022 18:00:30 +0200 Peter Boy wrote:
Any recommendations and/or experiences?
Is it really gone, or are they simply not creating the rc.local file any longer? I'm pretty sure I remember it working the last time I used it, just had to make the file myself and make it executable.
using the rc.local is going to be easier to support than creating your own systemd service to do exactly the same thing.
I have been using the rc.local stuff for a while for anything that does not have a native systemd unit file.
I think the comment of not using it is for other developers to not put into their instructions to add xxx to rc.local and telling them to create a proper systemd unit file.
There have always been a lot of projects out there that just say add it to rc.local and do not create a proper startup script to be used.
On Mon, Jul 18, 2022 at 11:01 AM Peter Boy pboy@uni-bremen.de wrote:
I have to run some scripts at the end of the boot process to establish various workarounds for bugs in systemd. In the days of System V, /etc/rc.d/rc.local would be the right place for this.
My research revealed several solutions with conflicting recommendations: (a) There is - also in Fedora - systemd-rc-local service. In the man file it is advised not to use it. A Fedora default installation also does not completely create the necessary directory structure. And if one wants to execute this service as far as possible at the end of the boot process, further adjustments are necessary.
(b) There is the DIY suggestion to create a service of one's own, and to place it as far as possible at the end of the system start.
(c) A suggestion is to insert in the root-crontab at the end @reboot systemctl start ….
The latter seems to be the most reliable solution at the moment.
Any recommendations and/or experiences?
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 7/18/22 09:00, Peter Boy wrote:
I have to run some scripts at the end of the boot process to establish various workarounds for bugs in systemd. In the days of System V, /etc/rc.d/rc.local would be the right place for this.
My research revealed several solutions with conflicting recommendations: (a) There is - also in Fedora - systemd-rc-local service. In the man file it is advised not to use it. A Fedora default installation also does not completely create the necessary directory structure. And if one wants to execute this service as far as possible at the end of the boot process, further adjustments are necessary.
(b) There is the DIY suggestion to create a service of one's own, and to place it as far as possible at the end of the system start.
(c) A suggestion is to insert in the root-crontab at the end @reboot systemctl start ….
The latter seems to be the most reliable solution at the moment.
/etc/rc.local must be set executable
If I remember correctly, systemd will execute rc-local.service which checks for /etc/rc.local then checks if it is executable. If so, it executes /etc/rc.local.
On 7/18/22 10:47, Tom Horsley wrote:
On Mon, 18 Jul 2022 10:38:03 -0700 Mike Wright wrote:
/etc/rc.local
I think it is some more obscure location like /etc/rc.d/rc.local.
[Unit] Description=/etc/rc.local Compatibility Documentation=man:systemd-rc-local-generator(8) ConditionFileIsExecutable=/etc/rc.local After=network.target
[Service] Type=forking ExecStart=/etc/rc.local start <--- TimeoutSec=0 RemainAfterExit=yes GuessMainPID=no
On Mon, Jul 18, 2022 at 10:52:42AM -0700, Mike Wright wrote:
On 7/18/22 10:47, Tom Horsley wrote:
On Mon, 18 Jul 2022 10:38:03 -0700 Mike Wright wrote:
/etc/rc.local
I think it is some more obscure location like /etc/rc.d/rc.local.
[Unit] Description=/etc/rc.local Compatibility Documentation=man:systemd-rc-local-generator(8) ConditionFileIsExecutable=/etc/rc.local After=network.target
[Service] Type=forking ExecStart=/etc/rc.local start <--- TimeoutSec=0 RemainAfterExit=yes GuessMainPID=no
Other tidbits:
/usr/share/man/man8/systemd-rc-local-generator.8.gz
/usr/lib/systemd/system-generators/systemd-rc-local-generator
I got it finally working.
Am 18.07.2022 um 18:08 schrieb Tom Horsley horsley1953@gmail.com:
Is it really gone, or are they simply not creating the rc.local file any longer?
The file is really gone. You have to create it at the right location.
The documentation is inconsistent. Some say /etc/rc.local, some /etc/rc.d/rc.local. The latter is correct.
What I did:
(1) Create /etc/rc.d/rc.local (with bash shebang), put in the execute commands needed, made it executable for user und group root (but just user root should be ok).
(2) Executed /usr/lib/systemd/system-generators/systemd-rc-local-generator
Is not on the path, you have to enter the complete path yourself - great. This step is indispensable!
(3) Reboot, voila the included programs got started.
I think, this is a better way than to hide the execute commands in user root’s crontab.
Thanks for all the support!
Am 18.07.2022 um 22:18 schrieb Peter Boy pboy@uni-bremen.de:
I got it finally working.
After some tests: It isn’t.
The programs I have to start depend on the existence of some (virtual) network interfaces. rc.local is ordered after network.target, which doesn’t mean, the network is functional then. Therefore, the program start via rc.local is in indeterministic process. Sometimes it works, sometimes not, sometimes only for some.
Documentation mentions a drop in at /etc/systemd/system/rc-local.service.d/network.conf. But there is no subdirectory /etc/systemd/system/rc-local.service.d/
Should I really mess around with vim and mkdir in the directories managed by the distribution? Seems like a bad idea to me.
Or have I missed something?
Am 18.07.2022 um 18:08 schrieb Tom Horsley horsley1953@gmail.com:
Is it really gone, or are they simply not creating the rc.local file any longer?
The file is really gone. You have to create it at the right location.
The documentation is inconsistent. Some say /etc/rc.local, some /etc/rc.d/rc.local. The latter is correct.
What I did:
(1) Create /etc/rc.d/rc.local (with bash shebang), put in the execute commands needed, made it executable for user und group root (but just user root should be ok).
(2) Executed /usr/lib/systemd/system-generators/systemd-rc-local-generator
Is not on the path, you have to enter the complete path yourself - great. This step is indispensable!
(3) Reboot, voila the included programs got started.
I think, this is a better way than to hide the execute commands in user root’s crontab.
Thanks for all the support! _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Monday, July 18, 2022 4:50:03 PM EDT Peter Boy wrote:
Am 18.07.2022 um 22:18 schrieb Peter Boy pboy@uni-bremen.de:
I got it finally working.
After some tests: It isn’t.
The programs I have to start depend on the existence of some (virtual) network interfaces. rc.local is ordered after network.target, which doesn’t mean, the network is functional then. Therefore, the program start via rc.local is in indeterministic process. Sometimes it works, sometimes not, sometimes only for some.
You probably should (carefully) read this:
https://systemd.io/NETWORK_ONLINE/
and then create a .service file to run whatever program you want to start at boot-time.
On Mon, 18 Jul 2022 22:50:03 +0200 Peter Boy wrote:
The programs I have to start depend on the existence of some (virtual) network interfaces.
Yea, when I was doing stuff with rc.local I had that problem as well. What I wound up doing was using the "at" command to start the scripts I really wanted to run about 20 or 30 seconds after rc.local is executed (picking time delays that always seemed to work well enough).
P.S. You can't just do a "sleep" because systemd hates rc.local jobs that don't finish right away and kills them off (or it did at one time anyway). Using the "at" command runs them separately so systemd is no longer involved.
On Mon, 2022-07-18 at 22:18 +0200, Peter Boy wrote:
The documentation is inconsistent. Some say /etc/rc.local, some /etc/rc.d/rc.local. The latter is correct.
On my other OS, /etc/rc.local is a symlink to the other one, which must be chmod +x (it starts off without it).
I dare say the linking is so that it works where older users expect it to be, before they move it to the newer location (where it makes no sense, since what you put in it is not a daemon).
Am 18.07.2022 um 23:17 schrieb Garry T. Williams gtwilliams@gmail.com:
and then create a .service file to run whatever program you want to start at boot-time.
Yeah, that’s the correct way. But in my case I don’t need a permanent solution (hopefully). I have to start some systemd containers, which of course already have a service file. Unfortunately, the autostart function doesn’t work, specifically with virtual interfaces of the host which the container depends on. I proposed a bug fix using network-online target instead of network target. It worked until F35, but with F36 the autostart function is removed and made a „FutureFeature“. So it is „broken by design“, but hopefully temporarily (whatever that means in terms of the timeframe).
On Mon, Jul 18, 2022 at 10:50:03PM +0200, Peter Boy wrote:
Am 18.07.2022 um 22:18 schrieb Peter Boy pboy@uni-bremen.de:
I got it finally working.
After some tests: It isn’t.
The programs I have to start depend on the existence of some (virtual) network interfaces. rc.local is ordered after network.target, which doesn’t mean, the network is functional then. Therefore, the program start via rc.local is in indeterministic process. Sometimes it works, sometimes not, sometimes only for some.
Maybe this from: SYSTEMD-RC-LOCAL-GENERATOR(8)
Also note that rc-local.service is ordered after network.target, which does not mean that the network is functional, see systemd.special(7).
If the script requires a configured network connection, it may be desirable to pull in and order it after network-online.target with a drop-in:
# /etc/systemd/system/rc-local.service.d/network.conf [Unit] Wants=network-online.target After=network-online.target
Documentation mentions a drop in at /etc/systemd/system/rc-local.service.d/network.conf. But there is no subdirectory /etc/systemd/system/rc-local.service.d/
Should I really mess around with vim and mkdir in the directories managed by the distribution? Seems like a bad idea to me.
Or have I missed something?
Am 18.07.2022 um 18:08 schrieb Tom Horsley horsley1953@gmail.com:
Is it really gone, or are they simply not creating the rc.local file any longer?
The file is really gone. You have to create it at the right location.
The documentation is inconsistent. Some say /etc/rc.local, some /etc/rc.d/rc.local. The latter is correct.
What I did:
(1) Create /etc/rc.d/rc.local (with bash shebang), put in the execute commands needed, made it executable for user und group root (but just user root should be ok).
(2) Executed /usr/lib/systemd/system-generators/systemd-rc-local-generator
Is not on the path, you have to enter the complete path yourself - great. This step is indispensable!
(3) Reboot, voila the included programs got started.
I think, this is a better way than to hide the execute commands in user root’s crontab.
Thanks for all the support! _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
End of included message <<<
On 18Jul2022 22:50, Peter Boy pboy@uni-bremen.de wrote:
Am 18.07.2022 um 22:18 schrieb Peter Boy pboy@uni-bremen.de: I got it finally working.
After some tests: It isn’t.
The programs I have to start depend on the existence of some (virtual) network interfaces. rc.local is ordered after network.target, which doesn’t mean, the network is functional then. Therefore, the program start via rc.local is in indeterministic process. Sometimes it works, sometimes not, sometimes only for some.
Documentation mentions a drop in at /etc/systemd/system/rc-local.service.d/network.conf. But there is no subdirectory /etc/systemd/system/rc-local.service.d/
Should I really mess around with vim and mkdir in the directories managed by the distribution? Seems like a bad idea to me.
Not to mention messy and annoying.
I've got a personal script called "await" which waits for a condition to become true (by polling). If you can write a command which tests the virtual interface (maybe "ping -c 3 -q virt-addr" or checking for a route?) you could go:
( await virt-network-check-command-here start programs ... ) &
in your rc.local file. Simple and direct.
Cheers, Cameron Simpson cs@cskk.id.au
Am 19.07.2022 um 07:10 schrieb Jon LaBadie jonfu@jgcomp.com:
On Mon, Jul 18, 2022 at 10:50:03PM +0200, Peter Boy wrote:
...
Maybe this from: SYSTEMD-RC-LOCAL-GENERATOR(8) Also note that rc-local.service is ordered after network.target, which does not mean that the network is functional, see systemd.special(7).
If the script requires a configured network connection, it may be desirable to pull in and order it after network-online.target with a drop-in:
# /etc/systemd/system/rc-local.service.d/network.conf [Unit] Wants=network-online.target After=network-online.target
Yes, I found that, too, and followed the instruction. And since then I have not found any other problems with the autostart. I now hope that the bug will be fixed as soon as possible.
-
Cameron Simpson -
Garry T. Williams -
Jon LaBadie -
Mike Wright -
Peter Boy -
Roger Heflin -
Tim -
Tom Horsley