delayed autostart of containers - ?
Hi guys. Would you know how, if possible at all, to delay an autostart of a container? My specific scenario is such in which containers- auto-started by systemd - reside under a net mount-point which is mounted at later stage by ha/pcs(so containers fail to start @boot) I'd hope that it's doable without extra & "external" scripts/tools. many thanks, L
On Mon, Sep 05, 2022 at 11:56:11AM +0100, lejeczek via Podman wrote:
Hi guys.
Would you know how, if possible at all, to delay an autostart of a container?
My specific scenario is such in which containers- auto-started by systemd - reside under a net mount-point which is mounted at later stage by ha/pcs(so containers fail to start @boot) I'd hope that it's doable without extra & "external" scripts/tools.
The way I'd handle that is with ExecStartPre in systemd; have it run a script that checks occassionally to see if the thing it needs is running.
I think you could use 'RequiresMountsFor=...' in your unit, see https://www.freedesktop.org/software/systemd/man/systemd.unit.html#RequiresM... On Tue, Sep 6, 2022 at 7:56 PM Robin Lee Powell <robinleepowell@gmail.com> wrote:
On Mon, Sep 05, 2022 at 11:56:11AM +0100, lejeczek via Podman wrote:
Hi guys.
Would you know how, if possible at all, to delay an autostart of a container?
My specific scenario is such in which containers- auto-started by systemd - reside under a net mount-point which is mounted at later stage by ha/pcs(so containers fail to start @boot) I'd hope that it's doable without extra & "external" scripts/tools.
The way I'd handle that is with ExecStartPre in systemd; have it run a script that checks occassionally to see if the thing it needs is running. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On 9/5/22 06:56, lejeczek via Podman wrote:
Hi guys.
Would you know how, if possible at all, to delay an autostart of a container?
My specific scenario is such in which containers- auto-started by systemd - reside under a net mount-point which is mounted at later stage by ha/pcs(so containers fail to start @boot) I'd hope that it's doable without extra & "external" scripts/tools.
many thanks, L
_______________________________________________ Podman mailing list --podman@lists.podman.io To unsubscribe send an email topodman-leave@lists.podman.io
Auto started containers in podman are started by the following unit files at boot time. /usr/lib/systemd/system/podman-restart.service /usr/lib/systemd/user/podman-restart.service Could you make sure that your unit file starts prior to these?
On 06/09/2022 11:56, Daniel Walsh wrote:
On 9/5/22 06:56, lejeczek via Podman wrote:
Hi guys.
Would you know how, if possible at all, to delay an autostart of a container?
My specific scenario is such in which containers- auto-started by systemd - reside under a net mount-point which is mounted at later stage by ha/pcs(so containers fail to start @boot) I'd hope that it's doable without extra & "external" scripts/tools.
many thanks, L
_______________________________________________ Podman mailing list --podman@lists.podman.io To unsubscribe send an email topodman-leave@lists.podman.io
Auto started containers in podman are started by the following unit files at boot time.
/usr/lib/systemd/system/podman-restart.service /usr/lib/systemd/user/podman-restart.service
Could you make sure that your unit file starts prior to these?
Now, with bit more tampering, I realize that the bit I "skipped" might be crucial to the question - it is about rootless containers. User's home - who owns containers - also resides under the same mount point (different path). So what happens when I 'ssh' to the user is: -> $ ssh appo@localhost -> $ systemctl --user status -l xyz.service Unit xyz.service could not be found. I have to: -> $ systemctl --user daemon-reload in order the have 'systemd' pick up such "missing" services which belong to the user, but!!... that does make 'systemd' start such container, though now it sees those containers, containers stay "inactive" I presume it might be more tricky with 'rootless' containers, a scenario such as mine. thanks, L.
On Wed, Sep 14, 2022 at 10:36:46AM +0100, lejeczek via Podman wrote:
On 06/09/2022 11:56, Daniel Walsh wrote:
On 9/5/22 06:56, lejeczek via Podman wrote:
Hi guys.
Would you know how, if possible at all, to delay an autostart of a container?
My specific scenario is such in which containers- auto-started by systemd - reside under a net mount-point which is mounted at later stage by ha/pcs(so containers fail to start @boot) I'd hope that it's doable without extra & "external" scripts/tools.
many thanks, L
_______________________________________________ Podman mailing list --podman@lists.podman.io To unsubscribe send an email topodman-leave@lists.podman.io
Auto started containers in podman are started by the following unit files at boot time.
/usr/lib/systemd/system/podman-restart.service /usr/lib/systemd/user/podman-restart.service
Could you make sure that your unit file starts prior to these?
Now, with bit more tampering, I realize that the bit I "skipped" might be crucial to the question - it is about rootless containers. User's home - who owns containers - also resides under the same mount point (different path). So what happens when I 'ssh' to the user is:
-> $ ssh appo@localhost -> $ systemctl --user status -l xyz.service Unit xyz.service could not be found.
I have to: -> $ systemctl --user daemon-reload in order the have 'systemd' pick up such "missing" services which belong to the user, but!!... that does make 'systemd' start such container, though now it sees those containers, containers stay "inactive"
I presume it might be more tricky with 'rootless' containers, a scenario such as mine.
Not exactly directly related, but if you're doing that you probably want to know about linger, which is how user units get started on system start without each user having to log in: https://wiki.archlinux.org/title/systemd/User#Automatic_start-up_of_systemd_...
On 14/09/2022 16:24, Robin Lee Powell wrote:
On Wed, Sep 14, 2022 at 10:36:46AM +0100, lejeczek via Podman wrote:
On 06/09/2022 11:56, Daniel Walsh wrote:
On 9/5/22 06:56, lejeczek via Podman wrote:
Hi guys.
Would you know how, if possible at all, to delay an autostart of a container?
My specific scenario is such in which containers- auto-started by systemd - reside under a net mount-point which is mounted at later stage by ha/pcs(so containers fail to start @boot) I'd hope that it's doable without extra & "external" scripts/tools.
many thanks, L
_______________________________________________ Podman mailing list --podman@lists.podman.io To unsubscribe send an email topodman-leave@lists.podman.io Auto started containers in podman are started by the following unit files at boot time.
/usr/lib/systemd/system/podman-restart.service /usr/lib/systemd/user/podman-restart.service
Could you make sure that your unit file starts prior to these?
Now, with bit more tampering, I realize that the bit I "skipped" might be crucial to the question - it is about rootless containers. User's home - who owns containers - also resides under the same mount point (different path). So what happens when I 'ssh' to the user is:
-> $ ssh appo@localhost -> $ systemctl --user status -l xyz.service Unit xyz.service could not be found.
I have to: -> $ systemctl --user daemon-reload in order the have 'systemd' pick up such "missing" services which belong to the user, but!!... that does make 'systemd' start such container, though now it sees those containers, containers stay "inactive"
I presume it might be more tricky with 'rootless' containers, a scenario such as mine.
Not exactly directly related, but if you're doing that you probably want to know about linger, which is how user units get started on system start without each user having to log in: https://wiki.archlinux.org/title/systemd/User#Automatic_start-up_of_systemd_...
"linger" does not help here or, it does not work the way you & I though for such case(s) with user home net mounted. (not in CentOS 8s with systemd-239-67.el8.x86_64) thanks, L.
participants (4)
-
Daniel Walsh -
lejeczek -
Paul Holzinger -
Robin Lee Powell