[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Ivan Sergeev]

Add and enable a systemd unit file to bring up / down network with ifup /
ifdown, analogous to the skeleton/etc/init.d/S40network init script.

Signed-off-by: Ivan Sergeev <vsergeev@kumunetworks.com>
---
 .../system/multi-user.target.wants/network.service  |  1 +
 system/skeleton/etc/systemd/system/network.service  | 21 +++++++++++++++++++++
 2 files changed, 22 insertions(+)
 create mode 120000 system/skeleton/etc/systemd/system/multi-user.target.wants/network.service
 create mode 100644 system/skeleton/etc/systemd/system/network.service

diff --git a/system/skeleton/etc/systemd/system/multi-user.target.wants/network.service b/system/skeleton/etc/systemd/system/multi-user.target.wants/network.service
new file mode 120000
index 0000000..d3558f9
--- /dev/null
+++ b/system/skeleton/etc/systemd/system/multi-user.target.wants/network.service
@@ -0,0 +1 @@
+../network.service
\ No newline at end of file
diff --git a/system/skeleton/etc/systemd/system/network.service b/system/skeleton/etc/systemd/system/network.service
new file mode 100644
index 0000000..0d77bb8
--- /dev/null
+++ b/system/skeleton/etc/systemd/system/network.service
@@ -0,0 +1,21 @@
+[Unit]
+Description=Network Connectivity
+Wants=network.target
+Before=network.target
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+
+# lo is brought up earlier, which will cause the upcoming "ifup -a" to fail
+# with exit code 1, due to an "ip: RTNETLINK answers: File exists" error during
+# its "ip addr add ..." command, subsequently causing this unit to fail even
+# though it is a benign error. Flushing the lo address with the command below
+# before ifup prevents this failure.
+ExecStart=/sbin/ip addr flush dev lo
+
+ExecStart=/sbin/ifup -a
+ExecStop=/sbin/ifdown -a
+
+[Install]
+WantedBy=multi-user.target
-- 
1.8.4.2

[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Thomas Petazzoni]

Dear Ivan Sergeev,

On Thu,  2 Jan 2014 17:38:32 -0800, Ivan Sergeev wrote:
> Add and enable a systemd unit file to bring up / down network with ifup /
> ifdown, analogous to the skeleton/etc/init.d/S40network init script.
> 
> Signed-off-by: Ivan Sergeev <vsergeev@kumunetworks.com>
> ---
>  .../system/multi-user.target.wants/network.service  |  1 +
>  system/skeleton/etc/systemd/system/network.service  | 21 +++++++++++++++++++++
>  2 files changed, 22 insertions(+)
>  create mode 120000 system/skeleton/etc/systemd/system/multi-user.target.wants/network.service
>  create mode 100644 system/skeleton/etc/systemd/system/network.service

We probably want to make that conditional on the type of init system
that is used, no?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Ivan Sergeev]

Hah, sorry. I forgot the reply all. This was supposed to be my follow up
discussion email:

Hello buildroot,

I'm submitting this in hopes of catching up network init in systemd with
that of busybox init, which is currently served by /etc/init.d/S40network.
This patch adds and enables network.service (which assumes ifup / ifdown
exists and uses them like /etc/init.d/S40network does).

I also wanted to bring up a more general issue:

Currently, it seems that the /etc/init.d scripts are copied over blindly
from the target skeleton to the target even if systemd (and not busybox) is
the chosen init system. Moving forward, having both busybox and systemd
init files in the skeleton, like this patch would have, will always clutter
/etc/ with some unused init files in the target system, since only one init
system will be active.

Should such init files be conditional targets in system/system.mk?  Or
should S40network be owned and copied over by package/busybox, and
network.service be owned and copied over by package/systemd, instead of
having them included statically in the target skeleton?

Thanks,
~vsergeev
Ivan Sergeev


On Fri, Jan 3, 2014 at 11:13 AM, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:

> Dear Ivan Sergeev,
>
> On Thu,  2 Jan 2014 17:38:32 -0800, Ivan Sergeev wrote:
> > Add and enable a systemd unit file to bring up / down network with ifup /
> > ifdown, analogous to the skeleton/etc/init.d/S40network init script.
> >
> > Signed-off-by: Ivan Sergeev <vsergeev@kumunetworks.com>
> > ---
> >  .../system/multi-user.target.wants/network.service  |  1 +
> >  system/skeleton/etc/systemd/system/network.service  | 21
> +++++++++++++++++++++
> >  2 files changed, 22 insertions(+)
> >  create mode 120000
> system/skeleton/etc/systemd/system/multi-user.target.wants/network.service
> >  create mode 100644 system/skeleton/etc/systemd/system/network.service
>
> We probably want to make that conditional on the type of init system
> that is used, no?
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140103/5487751a/attachment.html>

[Buildroot] [PATCH 1/1] systemd: add network unit file

[Ivan Sergeev]

Add and enable a systemd unit file to bring up or down network with ifup /
ifdown, analogous to the skeleton/etc/init.d/S40network init script.

Signed-off-by: Ivan Sergeev <vsergeev@kumunetworks.com>
---
 package/systemd/network.service | 21 +++++++++++++++++++++
 package/systemd/systemd.mk      |  9 +++++++++
 2 files changed, 30 insertions(+)
 create mode 100644 package/systemd/network.service

diff --git a/package/systemd/network.service b/package/systemd/network.service
new file mode 100644
index 0000000..0d77bb8
--- /dev/null
+++ b/package/systemd/network.service
@@ -0,0 +1,21 @@
+[Unit]
+Description=Network Connectivity
+Wants=network.target
+Before=network.target
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+
+# lo is brought up earlier, which will cause the upcoming "ifup -a" to fail
+# with exit code 1, due to an "ip: RTNETLINK answers: File exists" error during
+# its "ip addr add ..." command, subsequently causing this unit to fail even
+# though it is a benign error. Flushing the lo address with the command below
+# before ifup prevents this failure.
+ExecStart=/sbin/ip addr flush dev lo
+
+ExecStart=/sbin/ifup -a
+ExecStop=/sbin/ifdown -a
+
+[Install]
+WantedBy=multi-user.target
diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index a5dc8e5..a99c0da 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -72,7 +72,16 @@ define SYSTEMD_INSTALL_TTY_HOOK
 	ln -fs ../../../../usr/lib/systemd/system/serial-getty at .service $(TARGET_DIR)/etc/systemd/system/getty.target.wants/serial-getty@$(BR2_TARGET_GENERIC_GETTY_PORT).service
 endef
 
+define SYSTEMD_INSTALL_NETWORK_HOOK
+	$(INSTALL) -D -m 644 package/systemd/network.service \
+		$(TARGET_DIR)/etc/systemd/system/network.service
+	mkdir -p $(TARGET_DIR)/etc/systemd/system/multi-user.target.wants
+	ln -fs ../network.service \
+		$(TARGET_DIR)/etc/systemd/system/multi-user.target.wants/network.service
+endef
+
 SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
 	SYSTEMD_INSTALL_TTY_HOOK \
+	SYSTEMD_INSTALL_NETWORK_HOOK
 
 $(eval $(autotools-package))
-- 
1.8.5.3

[Buildroot] [PATCH 1/1] systemd: add network unit file

[Thomas Petazzoni]

Eric,

As our systemd person, could you have a look at this patch, and give
your comments and/or Acked-by/Reviewed-by as appropriate?

Thanks!

Thomas

On Mon, 27 Jan 2014 17:54:57 -0800, Ivan Sergeev wrote:
> Add and enable a systemd unit file to bring up or down network with ifup /
> ifdown, analogous to the skeleton/etc/init.d/S40network init script.
> 
> Signed-off-by: Ivan Sergeev <vsergeev@kumunetworks.com>
> ---
>  package/systemd/network.service | 21 +++++++++++++++++++++
>  package/systemd/systemd.mk      |  9 +++++++++
>  2 files changed, 30 insertions(+)
>  create mode 100644 package/systemd/network.service
> 
> diff --git a/package/systemd/network.service b/package/systemd/network.service
> new file mode 100644
> index 0000000..0d77bb8
> --- /dev/null
> +++ b/package/systemd/network.service
> @@ -0,0 +1,21 @@
> +[Unit]
> +Description=Network Connectivity
> +Wants=network.target
> +Before=network.target
> +
> +[Service]
> +Type=oneshot
> +RemainAfterExit=yes
> +
> +# lo is brought up earlier, which will cause the upcoming "ifup -a" to fail
> +# with exit code 1, due to an "ip: RTNETLINK answers: File exists" error during
> +# its "ip addr add ..." command, subsequently causing this unit to fail even
> +# though it is a benign error. Flushing the lo address with the command below
> +# before ifup prevents this failure.
> +ExecStart=/sbin/ip addr flush dev lo
> +
> +ExecStart=/sbin/ifup -a
> +ExecStop=/sbin/ifdown -a
> +
> +[Install]
> +WantedBy=multi-user.target
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index a5dc8e5..a99c0da 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -72,7 +72,16 @@ define SYSTEMD_INSTALL_TTY_HOOK
>  	ln -fs ../../../../usr/lib/systemd/system/serial-getty at .service $(TARGET_DIR)/etc/systemd/system/getty.target.wants/serial-getty@$(BR2_TARGET_GENERIC_GETTY_PORT).service
>  endef
>  
> +define SYSTEMD_INSTALL_NETWORK_HOOK
> +	$(INSTALL) -D -m 644 package/systemd/network.service \
> +		$(TARGET_DIR)/etc/systemd/system/network.service
> +	mkdir -p $(TARGET_DIR)/etc/systemd/system/multi-user.target.wants
> +	ln -fs ../network.service \
> +		$(TARGET_DIR)/etc/systemd/system/multi-user.target.wants/network.service
> +endef
> +
>  SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
>  	SYSTEMD_INSTALL_TTY_HOOK \
> +	SYSTEMD_INSTALL_NETWORK_HOOK
>  
>  $(eval $(autotools-package))



-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] systemd: add network unit file

[Eric Le Bihan]

Thomas, Ivan,

On Wed, Jun 11, 2014 at 10:34:47PM +0200, Thomas Petazzoni wrote:
> Eric,
>
> As our systemd person, could you have a look at this patch, and give
> your comments and/or Acked-by/Reviewed-by as appropriate?
>
I've tested the patch. It is OK, but I made some modifications:

- rebase
- the new network.service is not installed if systemd-networkd is selected, as
  they conflict.

The updated version can be found at http://patchwork.ozlabs.org/patch/359561/.

Best regards,
ELB

[Buildroot] [PATCH 1/1] systemd: add network unit file

[Thomas Petazzoni]

Dear Eric Le Bihan,

On Fri, 13 Jun 2014 17:42:43 +0200, Eric Le Bihan wrote:

> I've tested the patch. It is OK, but I made some modifications:
> 
> - rebase
> - the new network.service is not installed if systemd-networkd is selected, as
>   they conflict.
> 
> The updated version can be found at http://patchwork.ozlabs.org/patch/359561/.

Thanks, I've marked Ivan's patch as superseded in patchwork.

Thanks a lot for working on this!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Arnout Vandecappelle]

On 03/01/14 20:41, Ivan Sergeev wrote:
> Currently, it seems that the /etc/init.d scripts are copied over blindly
> from the target skeleton to the target even if systemd (and not busybox)
> is the chosen init system. Moving forward, having both busybox and
> systemd init files in the skeleton, like this patch would have, will
> always clutter /etc/ with some unused init files in the target system,
> since only one init system will be active.
>
> Should such init files be conditional targets in system/system.mk
> ?  Or should S40network be owned and copied over by
> package/busybox, and network.service be owned and copied over by
> package/systemd, instead of having them included statically in the target
> skeleton?

  I completely agree that the way it is done now is far from ideal.

  I think the best way to work with this would be to:

- remove the contents of the init.d directory from the skeleton;

- create a new skeleton fragment system/skeleton-init-sysv that contains 
etc/init.d;

- create a new skeleton fragment system/skeleton-init-systemd that 
contains whatever support files are needed by systemd (currently nothing, 
but your patch would add the networking unit file);

- copy the correct skeleton fragment as part of the .root target, but 
only if the default skeleton was selected - with a custom skeleton, it's 
up to the user to provide the right systemd/init.d;



  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Maxime Hadjinlian]

Hi all

On Tue, Jan 28, 2014 at 8:13 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 03/01/14 20:41, Ivan Sergeev wrote:
>>
>> Currently, it seems that the /etc/init.d scripts are copied over blindly
>> from the target skeleton to the target even if systemd (and not busybox)
>> is the chosen init system. Moving forward, having both busybox and
>> systemd init files in the skeleton, like this patch would have, will
>> always clutter /etc/ with some unused init files in the target system,
>> since only one init system will be active.
>>
>> Should such init files be conditional targets in system/system.mk
>> ?  Or should S40network be owned and copied over by
>> package/busybox, and network.service be owned and copied over by
>> package/systemd, instead of having them included statically in the target
>> skeleton?
>
>
>  I completely agree that the way it is done now is far from ideal.
>
>  I think the best way to work with this would be to:
>
> - remove the contents of the init.d directory from the skeleton;
>
> - create a new skeleton fragment system/skeleton-init-sysv that contains
> etc/init.d;
>
> - create a new skeleton fragment system/skeleton-init-systemd that contains
> whatever support files are needed by systemd (currently nothing, but your
> patch would add the networking unit file);
>
> - copy the correct skeleton fragment as part of the .root target, but only
> if the default skeleton was selected - with a custom skeleton, it's up to
> the user to provide the right systemd/init.d;
I  agree with you and as a matter of fact, I had already started
working on a patch that implement exactly this.

I would even like to go even further, as I have noticed that a lot of
the defined LIBFOO_INSTALL_INIT_SYSTEMD and LIBFOO_INSTALL_INIT_SYSV
almost always do the exact same stuff.
I would like for the infrastructure to take care of this, if no
function is defined, and a .service or S\d{0,2}*, then we should take
it and install it.

In that case, any particular requirements, the package define a
function, other than that, it's taken care of and we avoid duplicate
code in all the packages.

>
>
>
>  Regards,
>  Arnout
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Arnout Vandecappelle]

On 28/01/14 09:25, Maxime Hadjinlian wrote:
> Hi all
>
> On Tue, Jan 28, 2014 at 8:13 AM, Arnout Vandecappelle <arnout@mind.be> 
> wrote:
> > On 03/01/14 20:41, Ivan Sergeev wrote:
> >>
> >> Currently, it seems that the /etc/init.d scripts are copied over blindly
> >> from the target skeleton to the target even if systemd (and not busybox)
> >> is the chosen init system. Moving forward, having both busybox and
> >> systemd init files in the skeleton, like this patch would have, will
> >> always clutter /etc/ with some unused init files in the target system,
> >> since only one init system will be active.
> >>
> >> Should such init files be conditional targets in system/system.mk
> >> ?  Or should S40network be owned and copied over by
> >> package/busybox, and network.service be owned and copied over by
> >> package/systemd, instead of having them included statically in the 
> target
> >> skeleton?
> >
> >
> >   I completely agree that the way it is done now is far from ideal.
> >
> >   I think the best way to work with this would be to:
> >
> > - remove the contents of the init.d directory from the skeleton;
> >
> > - create a new skeleton fragment system/skeleton-init-sysv that contains
> > etc/init.d;
> >
> > - create a new skeleton fragment system/skeleton-init-systemd that 
> contains
> > whatever support files are needed by systemd (currently nothing, but your
> > patch would add the networking unit file);
> >
> > - copy the correct skeleton fragment as part of the .root target, but 
> only
> > if the default skeleton was selected - with a custom skeleton, it's up to
> > the user to provide the right systemd/init.d;
> I  agree with you and as a matter of fact, I had already started
> working on a patch that implement exactly this.
>
> I would even like to go even further, as I have noticed that a lot of
> the defined LIBFOO_INSTALL_INIT_SYSTEMD and LIBFOO_INSTALL_INIT_SYSV
> almost always do the exact same stuff.
> I would like for the infrastructure to take care of this, if no
> function is defined, and a .service or S\d{0,2}*, then we should take
> it and install it.

  Sounds like a great idea!

>
> In that case, any particular requirements, the package define a
> function, other than that, it's taken care of and we avoid duplicate
> code in all the packages.

  Probably the whole INSTALL_INIT_* stuff can even be removed - the 
number of packages that require special-casing is currently zero and may 
not ever be larger than zero. And if they do, it's not that difficult to 
make conditional post-install hooks.

  If you make a patch, don't forget to update the documentation!


  Regards,
  Arnout


>
> >
> >
> >
> >   Regards,
> >   Arnout
> >
> > --
> > Arnout Vandecappelle                          arnout at mind be
> > Senior Embedded Software Architect            +32-16-286500
> > Essensium/Mind                                http://www.mind.be
> > G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> > LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> > GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot


-- 
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Maxime Ripard]

On Tue, Jan 28, 2014 at 09:25:20AM +0100, Maxime Hadjinlian wrote:
> I would even like to go even further, as I have noticed that a lot of
> the defined LIBFOO_INSTALL_INIT_SYSTEMD and LIBFOO_INSTALL_INIT_SYSV
> almost always do the exact same stuff.
> I would like for the infrastructure to take care of this, if no
> function is defined, and a .service or S\d{0,2}*, then we should take
> it and install it.
> 
> In that case, any particular requirements, the package define a
> function, other than that, it's taken care of and we avoid duplicate
> code in all the packages.

Actually, there's two main issues that prevents this in the systemd
case, and are why we did it that way:
  - the multi-user-wants thing is actually comparable to the sysvinit
    runlevels. Some packages might want to set their units to other
    targets than multi-user (for example, graphical applications are
    likely to go in the graphical target, not the multi-user one)
  - Some units also takes "variables" from the created link names. For
    example, when you want to run getty, you just have a single getty
    unit, and the device to run getty on is set in the link name to
    that unit (so you'd end up with a link in multi-user.target.wants
    that will be getty.ttyS0.service, linking to
    /etc/systemd/system/getty.service).

At the time, we thought that in the systemd case, the easiest would be
to simply write down the 2-3 commands we need to setup the unit,
instead of having to give a whole bunch of variables. And we did the
same for sysvinit scripts, for consistency.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140128/bad2adac/attachment.asc>

[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Arnout Vandecappelle]

On 28/01/14 14:20, Maxime Ripard wrote:
> On Tue, Jan 28, 2014 at 09:25:20AM +0100, Maxime Hadjinlian wrote:
>> I would even like to go even further, as I have noticed that a lot of
>> the defined LIBFOO_INSTALL_INIT_SYSTEMD and LIBFOO_INSTALL_INIT_SYSV
>> almost always do the exact same stuff.
>> I would like for the infrastructure to take care of this, if no
>> function is defined, and a .service or S\d{0,2}*, then we should take
>> it and install it.
>>
>> In that case, any particular requirements, the package define a
>> function, other than that, it's taken care of and we avoid duplicate
>> code in all the packages.
>
> Actually, there's two main issues that prevents this in the systemd
> case, and are why we did it that way:
>    - the multi-user-wants thing is actually comparable to the sysvinit
>      runlevels. Some packages might want to set their units to other
>      targets than multi-user (for example, graphical applications are
>      likely to go in the graphical target, not the multi-user one)

  I disagree with this one. Buildroot's defaults should support only a 
single runlevel/target. That's how it's done for sysv init, and I'm very 
happy with it: it's dead easy to see which scripts will be executed at 
startup, you don't have to find out the runlevel etc. With systemd, 
things can become even more complex (because there can be several 
"targets" active at the same time IIRC), and I'd prefer to exclude this 
complexity by default.

  If a user requires several runlevels/targets, than most likely any 
default that buildroot provide will not fit anyway, so the user will have 
to manipulate things in their rootfs overlay or post-build script anyway. 
Therefore, I think it is better for the user if the defaults are simple 
and predictable.


>    - Some units also takes "variables" from the created link names. For
>      example, when you want to run getty, you just have a single getty
>      unit, and the device to run getty on is set in the link name to
>      that unit (so you'd end up with a link in multi-user.target.wants
>      that will be getty.ttyS0.service, linking to
>      /etc/systemd/system/getty.service).

  That is one of the special cases that would be handled in a 
post-install hook. But specifically for the getty case, it's not even 
necessary because we start only a single getty in the default setup, so 
we can directly install it to getty at ttyS0.service .


> At the time, we thought that in the systemd case, the easiest would be
> to simply write down the 2-3 commands we need to setup the unit,
> instead of having to give a whole bunch of variables. And we did the
> same for sysvinit scripts, for consistency.

  I think at the time, we mainly thought that we didn't know yet if the 
installation could be generalized. Now that we have a few packages that 
install unit files, it's more clear that they always to the same.

  Also, as far as I understand, the idea is not to add variables, but 
rather to check for the existence of package/foo/*.service and install that.


  Regards,
  Arnout

>
> Maxime
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Maxime Ripard]

On Tue, Jan 28, 2014 at 06:20:20PM +0100, Arnout Vandecappelle wrote:
> On 28/01/14 14:20, Maxime Ripard wrote:
> >On Tue, Jan 28, 2014 at 09:25:20AM +0100, Maxime Hadjinlian wrote:
> >>I would even like to go even further, as I have noticed that a lot of
> >>the defined LIBFOO_INSTALL_INIT_SYSTEMD and LIBFOO_INSTALL_INIT_SYSV
> >>almost always do the exact same stuff.
> >>I would like for the infrastructure to take care of this, if no
> >>function is defined, and a .service or S\d{0,2}*, then we should take
> >>it and install it.
> >>
> >>In that case, any particular requirements, the package define a
> >>function, other than that, it's taken care of and we avoid duplicate
> >>code in all the packages.
> >
> >Actually, there's two main issues that prevents this in the systemd
> >case, and are why we did it that way:
> >   - the multi-user-wants thing is actually comparable to the sysvinit
> >     runlevels. Some packages might want to set their units to other
> >     targets than multi-user (for example, graphical applications are
> >     likely to go in the graphical target, not the multi-user one)
> 
>  I disagree with this one. Buildroot's defaults should support only
> a single runlevel/target. That's how it's done for sysv init, and

Hmm, afaik, it's not done at all in the sysvinit case, because the
default sysvinit we use most of the time (busybox's) doesn't handle
the runlevel at all. It's not really the same story there.

> I'm very happy with it: it's dead easy to see which scripts will be
> executed at startup, you don't have to find out the runlevel etc.
> With systemd, things can become even more complex (because there can
> be several "targets" active at the same time IIRC), and I'd prefer
> to exclude this complexity by default.
> 
>  If a user requires several runlevels/targets, than most likely any
> default that buildroot provide will not fit anyway, so the user will
> have to manipulate things in their rootfs overlay or post-build
> script anyway. Therefore, I think it is better for the user if the
> defaults are simple and predictable.
> 
> 
> >   - Some units also takes "variables" from the created link names. For
> >     example, when you want to run getty, you just have a single getty
> >     unit, and the device to run getty on is set in the link name to
> >     that unit (so you'd end up with a link in multi-user.target.wants
> >     that will be getty.ttyS0.service, linking to
> >     /etc/systemd/system/getty.service).
> 
>  That is one of the special cases that would be handled in a
> post-install hook. But specifically for the getty case, it's not
> even necessary because we start only a single getty in the default
> setup, so we can directly install it to getty at ttyS0.service .

Which won't work if you don't have a different tty to export a shell
on, but yes, I get your point.

> >At the time, we thought that in the systemd case, the easiest would be
> >to simply write down the 2-3 commands we need to setup the unit,
> >instead of having to give a whole bunch of variables. And we did the
> >same for sysvinit scripts, for consistency.
> 
>  I think at the time, we mainly thought that we didn't know yet if
> the installation could be generalized. Now that we have a few
> packages that install unit files, it's more clear that they always
> to the same.

We have *three* packages with systemd units in current master. I
hardly see how you can generalize something out of 3 (similar)
samples.

>  Also, as far as I understand, the idea is not to add variables, but
> rather to check for the existence of package/foo/*.service and
> install that.

This also doesn't cover the case anymore where a package would ship
together with the source code a systemd unit file. I expect it to be
more and more common, and it's something that we will want to use most
of the time, and not duplicate the unit file in the buildroot package
itself.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140129/07705c21/attachment.asc>

[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Maxime Hadjinlian]

On Wed, Jan 29, 2014 at 9:26 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
>
>
> On Tue, Jan 28, 2014 at 06:20:20PM +0100, Arnout Vandecappelle wrote:
>> On 28/01/14 14:20, Maxime Ripard wrote:
>> >On Tue, Jan 28, 2014 at 09:25:20AM +0100, Maxime Hadjinlian wrote:
>> >>I would even like to go even further, as I have noticed that a lot of
>> >>the defined LIBFOO_INSTALL_INIT_SYSTEMD and LIBFOO_INSTALL_INIT_SYSV
>> >>almost always do the exact same stuff.
>> >>I would like for the infrastructure to take care of this, if no
>> >>function is defined, and a .service or S\d{0,2}*, then we should take
>> >>it and install it.
>> >>
>> >>In that case, any particular requirements, the package define a
>> >>function, other than that, it's taken care of and we avoid duplicate
>> >>code in all the packages.
>> >
>> >Actually, there's two main issues that prevents this in the systemd
>> >case, and are why we did it that way:
>> >   - the multi-user-wants thing is actually comparable to the sysvinit
>> >     runlevels. Some packages might want to set their units to other
>> >     targets than multi-user (for example, graphical applications are
>> >     likely to go in the graphical target, not the multi-user one)
>>
>>  I disagree with this one. Buildroot's defaults should support only
>> a single runlevel/target. That's how it's done for sysv init, and
>
> Hmm, afaik, it's not done at all in the sysvinit case, because the
> default sysvinit we use most of the time (busybox's) doesn't handle
> the runlevel at all. It's not really the same story there.
>
>> I'm very happy with it: it's dead easy to see which scripts will be
>> executed at startup, you don't have to find out the runlevel etc.
>> With systemd, things can become even more complex (because there can
>> be several "targets" active at the same time IIRC), and I'd prefer
>> to exclude this complexity by default.
>>
>>  If a user requires several runlevels/targets, than most likely any
>> default that buildroot provide will not fit anyway, so the user will
>> have to manipulate things in their rootfs overlay or post-build
>> script anyway. Therefore, I think it is better for the user if the
>> defaults are simple and predictable.
>>
>>
>> >   - Some units also takes "variables" from the created link names. For
>> >     example, when you want to run getty, you just have a single getty
>> >     unit, and the device to run getty on is set in the link name to
>> >     that unit (so you'd end up with a link in multi-user.target.wants
>> >     that will be getty.ttyS0.service, linking to
>> >     /etc/systemd/system/getty.service).
>>
>>  That is one of the special cases that would be handled in a
>> post-install hook. But specifically for the getty case, it's not
>> even necessary because we start only a single getty in the default
>> setup, so we can directly install it to getty at ttyS0.service .
>
> Which won't work if you don't have a different tty to export a shell
> on, but yes, I get your point.
>
>> >At the time, we thought that in the systemd case, the easiest would be
>> >to simply write down the 2-3 commands we need to setup the unit,
>> >instead of having to give a whole bunch of variables. And we did the
>> >same for sysvinit scripts, for consistency.
>>
>>  I think at the time, we mainly thought that we didn't know yet if
>> the installation could be generalized. Now that we have a few
>> packages that install unit files, it's more clear that they always
>> to the same.
>
> We have *three* packages with systemd units in current master. I
> hardly see how you can generalize something out of 3 (similar)
> samples.
Well to be fair, a *lot* of startup script (Whatever if it's SysV,
systemd, or another one), it is usually a single file starting a
binary with command line arguments. Nothing really fancy.
>
>>  Also, as far as I understand, the idea is not to add variables, but
>> rather to check for the existence of package/foo/*.service and
>> install that.
>
> This also doesn't cover the case anymore where a package would ship
> together with the source code a systemd unit file. I expect it to be
> more and more common, and it's something that we will want to use most
> of the time, and not duplicate the unit file in the buildroot package
> itself.
If a package ship with the unit file in its source code, there should
be a way to install it using the package configure/make or whatever is
provided for that. So you won't even copy the file, we won't need a
copy. Or if it's not possible, we would define the helper function,
and it will install it, which would avoid the copy again.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

[Peter Korsgaard]

>>>>> "Maxime" == Maxime Ripard <maxime.ripard@free-electrons.com> writes:

Hi,

 >> Also, as far as I understand, the idea is not to add variables, but
 >> rather to check for the existence of package/foo/*.service and
 >> install that.

 > This also doesn't cover the case anymore where a package would ship
 > together with the source code a systemd unit file. I expect it to be
 > more and more common, and it's something that we will want to use most
 > of the time, and not duplicate the unit file in the buildroot package
 > itself.

Good point. I would certainly not want us to write our own service files
if upstream provides a workable one.

-- 
Bye, Peter Korsgaard