Thanks, Andrei, for your response. Am Samstag, 25. Mai 2019, 13:40:57 CEST schrieb Andrei Borzenkov:

25.05.2019 13:48, Hans-Peter Jansen пишет:

...

Hi,

attempting to separate the virtualbox autostart feature from vboxdrv, because it bites me on every reboot...

I run vboxes with user privilege, but that's an LDAP user, only available after openldap¹ and sssd is up and alive. Now, a lot more user databases

Actually sssd is expected to cache user information exactly to make it available offline.

...

exist, and I don't want to add all systemd deps specifically...

Ordering after nss-user-lookup.target should be enough as long as services implementing user lookup correctly integrate itself before it. And if they do not, it needs to be reported as bug.

Okay, so that's a good enough target to try. Given, that VMs tend to create a *lot* of load, which would better delayed after regular boot services, doesn't boot-complete.target fit that bill? Here's, what I've come up with so far: [Unit] SourcePath=/usr/lib/virtualbox/vboxautostart.sh Description=VirtualBox Linux autostart module Requires=vboxdrv.service After=network.target After=time-sync.target After=nss-user-lookup.target [Service] ExecStart=/usr/lib/virtualbox/vboxautostart.sh start ExecStop=/usr/lib/virtualbox/vboxautostart.sh stop Type=oneshot RemainAfterExit=yes TimeoutStopSec=0 [Install] WantedBy=multi-user.target Wants=boot-complete.target The script starts/stops VMs synchronously for the specified users. Does this has a chance to operate as desired? Any other issues to note, suggestions for improvements are much appreciated.

...

Since systemd isn't the nicest player, when it comes to run services last,

Such remarks do not facilitate constructive replies. This topic has been beaten to death and if you have something new to add do it where it belongs - on systemd list.

You are right. Sorry for my childish comment. It should have read: "systemd doesn't pave an obvious way to run services last" but maybe, that's isn't true either, in the light of boot-complete.target, which potentially fits the bill.

...

Type=idle

seems to be the best way to delay its execution for me.

Other ideas? The motivation for delaying the vbox autostart should be obvious, and is not limited to this specific constellation..

Needless to say, but the shutdown should happen *first* in the reboot/halt procedure. Can you point me to services with similar requirements?

Units are stopped in reverse order so as long as startup dependencies are correct they should be stopped in correct order as well. Of course, this presumes your services actually stop when told to do so (i.e. stop request is reported as completed only after service is stopped). Quite often ExecStop just initiates long running stop sequence and exits.

Sure, will take care of that, and test it throughout. Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28/05/2019 07.38, Andrei Borzenkov wrote:

26.05.2019 15:35, Hans-Peter Jansen пишет:

...

Thanks, Andrei, for your response.

...

Given, that VMs tend to create a *lot* of load, which would better delayed after regular boot services, doesn't boot-complete.target fit that bill?

I do not know what boot-complete.target is. You may consider adding timer with OnStartupSec that starts your service; OnStartup comes as close to "after everything else" as can be expected given systemd architecture.

* The boot-complete.target target unit (see systemd.special(7)) serves as a generic extension point both for units that shall be considered necessary to consider a boot successful on one side (example: systemd-boot-check-no-failures.service as described above), and units that want to act only if the boot is successful on the other (example: systemd-bless-boot.service as described above). https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT.html Does not appear to exist on Leap; maybe on factory. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)