From: Christoph Heiss <c.heiss@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC PATCH installer 2/5] fix #5579: first-boot: add initial service packaging
Date: Fri, 15 Nov 2024 11:10:42 +0100 [thread overview]
Message-ID: <gpfamnyubnsvoljbzm4it6wb4pxmylsnrhnzurinqhbttiptjn@qia6nbyktcbq> (raw)
Thanks for chiming in!
On Fri, Nov 15, 2024 at 10:49:19AM +0100, Thomas Lamprecht wrote:
> Am 15.11.24 um 10:34 schrieb Christoph Heiss:
> > [..]
> > Should it be an enum then? I.e. only allowing certain values such as
> > - network-pre.target
> > - network.target
> > - network-online.target
> > - multi-user.target
>
> Yeah, I would not make it generic, just the two or three most common
> orderings, we can then extend it on potential future user demand.
Alright, that was my thought here too. A slight abstraction layer will
make things lot less confusing for users.
>
> I think before network, post network and finished boot, i.e. multi-user
> target seem enough for now.
Ack!
> [..]
> > Not sure if we could just use multi-user.target as a default target, but
> > systemd *should* pull it in and run it in the right ordering too with
> > e.g. {Before,Wants}=network-pre.target ?
>
> Isn't the WantedBy is more for defining the target the unit itself will
> be part of, or? Adapting that might indeed make sense, but a bit to long
> ago that I looked into systemd unit ordering/dependency semantics more
> closely.
>
Yeah, about the meaning AFAIU myself. I'll test with multi-user.target,
should then work in any case I think. But since we will control the
possible ordering targets anyway, it's not a big problem really after
all.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next reply other threads:[~2024-11-15 10:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-15 10:10 Christoph Heiss [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-11-13 13:59 [pve-devel] [RFC PATCH installer 0/5] fix #5579: allow specifying optional first-boot script Christoph Heiss
2024-11-13 13:59 ` [pve-devel] [RFC PATCH installer 2/5] fix #5579: first-boot: add initial service packaging Christoph Heiss
2024-11-14 20:23 ` Thomas Lamprecht
2024-11-15 9:34 ` Christoph Heiss
2024-11-15 9:49 ` Thomas Lamprecht
2024-11-15 13:34 ` Christoph Heiss
2024-11-15 13:39 ` Thomas Lamprecht
2024-11-15 13:43 ` Christoph Heiss
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=gpfamnyubnsvoljbzm4it6wb4pxmylsnrhnzurinqhbttiptjn@qia6nbyktcbq \
--to=c.heiss@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.