How does one run something at the end of the boot process in systemd, i.e. previously things that were put in boot.local?
Thanks, Robert
On Saturday, December 3 2011, 07:23:26, Robert Schweikert wrote:
How does one run something at the end of the boot process in systemd, i.e. previously things that were put in boot.local?
Thanks, Robert
boot.local is still supported by way of rc-local.service:
root@host:~ # systemctl status rc-local.service rc-local.service - /etc/init.d/boot.local Compatibility Loaded: loaded (/lib/systemd/system/rc-local.service; static) Active: active (exited) since Sat, 03 Dec 2011 14:51:42 +0100; 7min ago Process: 1183 ExecStart=/etc/init.d/boot.local (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/rc-local.service
Greets Mike
Le samedi 03 décembre 2011 à 15:05 +0100, Michael Buchau a écrit :
On Saturday, December 3 2011, 07:23:26, Robert Schweikert wrote:
How does one run something at the end of the boot process in systemd, i.e. previously things that were put in boot.local?
Thanks, Robert
boot.local is still supported by way of rc-local.service:
root@host:~ # systemctl status rc-local.service rc-local.service - /etc/init.d/boot.local Compatibility Loaded: loaded (/lib/systemd/system/rc-local.service; static) Active: active (exited) since Sat, 03 Dec 2011 14:51:42 +0100; 7min ago Process: 1183 ExecStart=/etc/init.d/boot.local (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/rc-local.service
yep.. Beware it might not be started as the really "last" service gefore getty..
On Mon, Dec 5, 2011 at 4:14 AM, Frederic Crozat fcrozat@suse.com wrote: [snip]
boot.local is still supported by way of rc-local.service:
[snip]
yep.. Beware it might not be started as the really "last" service gefore getty..
I worry about that, because I always used to use after.local in order to be sure that everything my local services needed was already up and running. It is easy enough to add after.local myself, but since it is no longer expected by systemd doing so would make me nervous, so I just put all my after.local scripting into boot.local and crossed my fingers. So far it seems to work, but I would be a happier camper if the concept of an after.local was still implemented by systemd.
Le lundi 05 décembre 2011 à 04:49 -0500, Mark Gray a écrit :
On Mon, Dec 5, 2011 at 4:14 AM, Frederic Crozat fcrozat@suse.com wrote: [snip]
boot.local is still supported by way of rc-local.service:
[snip]
yep.. Beware it might not be started as the really "last" service gefore getty..
I worry about that, because I always used to use after.local in order to be sure that everything my local services needed was already up and running. It is easy enough to add after.local myself, but since it is no longer expected by systemd doing so would make me nervous, so I just put all my after.local scripting into boot.local and crossed my fingers. So far it seems to work, but I would be a happier camper if the concept of an after.local was still implemented by systemd.
Unfortunately, since there is no "static list" of services, unlike sysvinit (which is why insserv was able to ensure non-LSB standard $ALL target), I don't expect it to happen.
If you want to play it safe, you could either write your own systemd service file and add "After= ..." with the service you want to be started before your own service. Or you can use timer feature from systemd, to start a service xx seconds after the systemd is "active" (ie boot is complete), see /lib/systemd/system/systemd-readahead-done.timer (and systemd-readahead-done.service as an example).
On Mon, Dec 5, 2011 at 5:11 AM, Frederic Crozat fcrozat@suse.com wrote:
Unfortunately, since there is no "static list" of services, unlike sysvinit (which is why insserv was able to ensure non-LSB standard $ALL target), I don't expect it to happen.
If you want to play it safe, you could either write your own systemd service file and add "After= ..." with the service you want to be started before your own service. Or you can use timer feature from systemd, to start a service xx seconds after the systemd is "active" (ie boot is complete), see /lib/systemd/system/systemd-readahead-done.timer (and systemd-readahead-done.service as an example).
As long as future upgrades respect local service files and do the right thing, this is certainly acceptable (the dropping of after.local has shaken my faith in upgrades slightly :)
On 12/05/2011 10:49 AM, Mark Gray wrote:
On Mon, Dec 5, 2011 at 4:14 AM, Frederic Crozatfcrozat@suse.com wrote: [snip]
boot.local is still supported by way of rc-local.service:
[snip]
yep.. Beware it might not be started as the really "last" service gefore getty..
I worry about that, because I always used to use after.local in order to be sure that everything my local services needed was already up and running. It is easy enough to add after.local myself, but since it is no longer expected by systemd doing so would make me nervous, so I just put all my after.local scripting into boot.local and crossed my fingers. So far it seems to work, but I would be a happier camper if the concept of an after.local was still implemented by systemd.
What is your use-case? Perhaps it can be solved differently
Andreas
On Mon, Dec 5, 2011 at 5:16 AM, Andreas Jaeger aj@suse.com wrote:
What is your use-case? Perhaps it can be solved differently
On the only computer where it matters, my after.local sets up my iptables (so networking should be up), and uses the --bind option of mount to "splice" my large archive disk into several places on my smaller root disk (so all file systems need to be mounted rw by then.)
So far putting these into boot.local works fine, but my reading of boot.local's use suggests it might be executed at most any point in the boot process, and after.local's used to be executed after the run level was reached.
On Monday, December 05, 2011 06:47:12 Mark Gray wrote:
On Mon, Dec 5, 2011 at 5:16 AM, Andreas Jaeger aj@suse.com wrote:
What is your use-case? Perhaps it can be solved differently
On the only computer where it matters, my after.local sets up my iptables (so networking should be up), and uses the --bind option of mount to "splice" my large archive disk into several places on my smaller root disk (so all file systems need to be mounted rw by then.)
So far putting these into boot.local works fine, but my reading of boot.local's use suggests it might be executed at most any point in the boot process, and after.local's used to be executed after the run level was reached.
You can create separate service for these, there shouldn't be a problem...
Andreas
On Mon, Dec 5, 2011 at 6:53 AM, Andreas Jaeger aj@suse.com wrote:
On Monday, December 05, 2011 06:47:12 Mark Gray wrote:
On Mon, Dec 5, 2011 at 5:16 AM, Andreas Jaeger aj@suse.com wrote:
What is your use-case? Perhaps it can be solved differently
On the only computer where it matters, my after.local sets up my iptables (so networking should be up), and uses the --bind option of mount to "splice" my large archive disk into several places on my smaller root disk (so all file systems need to be mounted rw by then.)
So far putting these into boot.local works fine, but my reading of boot.local's use suggests it might be executed at most any point in the boot process, and after.local's used to be executed after the run level was reached.
You can create separate service for these, there shouldn't be a problem...
Good enough -- I suppose I really should learn systemd. I have a premonition though that systemd's configuration "language" is going to undergo a major change before I die (like bind and grub2 did) making everything I learn about it obsolete :)
On 05/12/11 09:16, Mark Gray wrote:
Good enough -- I suppose I really should learn systemd. I have a premonition though that systemd's configuration "language" is going to undergo a major change before I die.
They are plain old INI files, the configuration options are likely to be expanded but I doubt already existent ones will change meaning.
On Mon, Dec 5, 2011 at 9:35 AM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
On 05/12/11 09:16, Mark Gray wrote:
Good enough -- I suppose I really should learn systemd. I have a premonition though that systemd's configuration "language" is going to undergo a major change before I die.
They are plain old INI files, the configuration options are likely to be expanded but I doubt already existent ones will change meaning.
That's what I thought before I bought and read "DNS and BIND" :)
Le lundi 05 décembre 2011 à 11:35 -0300, Cristian Rodríguez a écrit :
On 05/12/11 09:16, Mark Gray wrote:
Good enough -- I suppose I really should learn systemd. I have a premonition though that systemd's configuration "language" is going to undergo a major change before I die.
They are plain old INI files, the configuration options are likely to be expanded but I doubt already existent ones will change meaning.
On that subject, I recommend reading :
http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise
On 05/12/11 09:16, Mark Gray wrote:
Good enough -- I suppose I really should learn systemd.
yeah, that's a good idea, is fairly easy to configure and provide units for your custom tools, and most importantly, it works :-)
On 12/05/2011 06:53 AM, Andreas Jaeger wrote:
On Monday, December 05, 2011 06:47:12 Mark Gray wrote:
On Mon, Dec 5, 2011 at 5:16 AM, Andreas Jaegeraj@suse.com wrote:
What is your use-case? Perhaps it can be solved differently
On the only computer where it matters, my after.local sets up my iptables (so networking should be up), and uses the --bind option of mount to "splice" my large archive disk into several places on my smaller root disk (so all file systems need to be mounted rw by then.)
So far putting these into boot.local works fine, but my reading of boot.local's use suggests it might be executed at most any point in the boot process, and after.local's used to be executed after the run level was reached.
You can create separate service for these, there shouldn't be a problem...
Yes, no problem for things that run all the time. But for things that only run once and do not have a "formal" firstboot procedure it appears overkill. Previously a simple
if [ -f SOME_TRIGGER ]; then RUN_MY_ONETIME_SETUP REMOVE_THE_TRIGGER fi
did just fine. Of course I can set up a unit file for this but that just seems stupid.
What I don not know and have not tried is what happens when one installs yast2-firstboot and has no firstboot.xml. Wonder if a script in /usr/share/firstboot/scripts would be executed in this case.
In any event the key is one time automatic configuration (no keyboard, no monitor connected)
Robert
Hello,
Am Montag, 5. Dezember 2011 schrieb Mark Gray:
On Mon, Dec 5, 2011 at 5:16 AM, Andreas Jaeger aj@suse.com wrote: On the only computer where it matters, my after.local sets up my iptables (so networking should be up), and uses the --bind option of mount to "splice" my large archive disk into several places on my smaller root disk (so all file systems need to be mounted rw by then.)
You probably don't need a script for the bind-mounts, it should work with a fstab entry (add it after the entry that mounts /bigdisk):
/bigdisk/usr /usr none rw,bind
Regards,
Christian Boltz
Am 06.12.2011 00:39, schrieb Christian Boltz:
You probably don't need a script for the bind-mounts, it should work with a fstab entry (add it after the entry that mounts /bigdisk):
/bigdisk/usr /usr none rw,bind
yes, it definitely does, I'm using it like that:
seife@susi:~> grep bind /etc/fstab /local/libvirt /var/lib/libvirt none bind 0 0 /local/usr-lib-debug /usr/lib/debug none bind 0 0
On Mon, Dec 5, 2011 at 6:39 PM, Christian Boltz opensuse@cboltz.de wrote: [snip]
You probably don't need a script for the bind-mounts, it should work with a fstab entry (add it after the entry that mounts /bigdisk):
/bigdisk/usr /usr none rw,bind
Cool! I had suspected that that might work, but was too lazy to try, and my after.local was there already.