Re: [systemd-devel] experiments with 'minimal build'
On Fri, Mar 20, 2015 at 2:39 AM, Alison Chaiken wrote: > http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/ says that > the minimum requirements are udev and journald. I wonder if udev is > really needed if the kernel is completely statically compiled and > module loading is disabled? That is a common use case for many > embedded devices. > Yeah, we still need udev to populate /dev and manage device changes, all of which is still relevant even if the kernel has everything built in. (devtmpfs doesn't let us dump udev, either.) Thanks, Jeff ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] experiments with 'minimal build'
On Wed, Mar 18, 2015 at 6:07 PM, Alison Chaiken wrote: > 1. With ./configure --disable-gtk-doc --disable-seccomp > --disable-selinux --disable-apparmor --disable-xz --disable-zlib > --disable-pam --disable-acl --disable-smack --disable-gcrypt > --disable-audit --disable-elfutils --disable-libcryptsetup > --disable-qrencode --disable-microhttpd --disable-gnutls > --disable-libcurl --disable-libidn --disable-quotacheck > --disable-vconsole --disable-logind --disable-machined > --disable-importd --disable-hostnamed --disable-timedated > --disable-localed --disable-polkit --disable-resolved > --disable-networkd --disable-efi --disable-manpages > --disable-hibernate --disable-tests > > [achaiken@localhost systemd (master)]$ ./systemd --version > systemd 219 > -PAM -AUDIT -SELINUX +IMA -APPARMOR -SMACK +SYSVINIT +UTMP > -LIBCRYPTSETUP -GCRYPT -GNUTLS -ACL -XZ -LZ4 -SECCOMP +BLKID -ELFUTILS > +KMOD -IDN > I'm interested in minimal builds too, as I've been learning the ins and outs of systemd on a 32MB MIPS system about the size of a US quarter. (I learn best by repeatedly punching myself in the face.) Mantas clarified the memory measurement issue. It's one of those confusing things about Linux that hasn't improved in 20 years. Here's a 10 year old Perl script that occasionally comes in handy for more accurate memory management: http://lists.freedesktop.org/archives/gstreamer-devel/2004-April/007545.html But usually, RSS is a good enough indicator. Here's my build: # /usr/lib/systemd/systemd --version systemd 219 -PAM -AUDIT -SELINUX -IMA -APPARMOR -SMACK +SYSVINIT -UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS -ACL -XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN And because my tooling is somewhat limited on this device, here's the RSS straight from the source: # grep ^VmRSS /proc/1/status # systemd/init VmRSS: 2584 kB # grep ^VmRSS /proc/199/status # journald VmRSS: 1452 kB # grep ^VmRSS /proc/349/status # udevd VmRSS: 1372 kB # grep ^VmRSS /proc/356/status # dbus-daemon VmRSS: 1528 kB Even for my use case, booting directly into a squashfs filesystem, booting failed when I disabled blkid. That doesn't worry me too much, because ultimately systemd has to detect my flash (mtd) block devices, so it'll probably be needed anyway. (The on-disk footprint of libblkid on my system is 245.6K.) I haven't disabled kmod, but could. That will mean the systemd binary won't try to load unix, ipv6, and autofs4 modules when it starts, but I can build those modules into the kernel (or load them prior to starting systemd). The only trouble is that disabling kmod will disable systemd-modules-load. Not sure if I really need that, but it's something to keep in mind. It may be possible to patch out kmod use from systemd, such that only systemd-modules-load would bring it in, but I'm not sure it's worth it. (The on-disk footprint of libkmod on my system is 71.8K.) The last + is +SYSVINIT, but there doesn't appear to be a configure option to disable sysvinit compatibility anymore. From what I can tell, there's a bit of sysvinit-related logic in the systemd binary itself, but most of the icky bits are farmed off to helper binaries, such as the short-lived systemd-sysv-generator. The other part of minimal builds is on-disk footprint and avoiding implicit work. So, I've aggressively split up my OpenWrt packages to let builders choose what they need for their use case. This doesn't make a lot of sense in beefy desktop or server land, but it's measurably important for "embedded" deployments. For example, by splitting out (and not installing) the sysvinit compatibility support binaries, I save about 184K on-disk, plus a little bit of time during boot. :-) Here's my systemd packaging work for OpenWrt if anyone's interested (which reminds me, I really need to push my latest changes): https://github.com/jdub/openwrt-systemd Thanks, Jeff ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure
On Fri, Mar 13, 2015 at 10:11 AM, Lucas De Marchi wrote: > Both kmod and systemd are being crosscompiled for quite some time by yocto, > buildroot, etc It does interest me that buildroot doesn't have an equivalent change, despite (at least) pciutils depending on it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure
On Fri, Mar 13, 2015 at 10:11 AM, Lucas De Marchi wrote: > I can't but think this is just to conform to other (gnome) projects. These patches come from an absolutely non-GNOME environment (OpenWrt), but I'm appealing to an authority in actively maintained GNOME code as that's where pkg-config comes from and a project I'm historically familiar with. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure
On Fri, Mar 13, 2015 at 10:07 AM, Michael Biebl wrote: >> Those are the as-installed versions (they're not manipulated again during >> make). > > And how does that improve cross-compilation? It allows you to successfully build other software that uses the library. A minor detail. :-) Thanks, Jeff ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure
On Fri, Mar 13, 2015 at 8:53 AM, Zbigniew Jędrzejewski-Szmek wrote: > So you prefer the second version to the first, right? Does not > exec_prefix get assigned and then substituted, leading to an identical > result? Those are the as-installed versions (they're not manipulated again during make). Here's an example from GNOME land: https://git.gnome.org/browse/gjs/tree/configure.ac#n232 https://git.gnome.org/browse/gjs/tree/Makefile.am#n72 Thanks, Jeff ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure
On Thu, Mar 12, 2015 at 6:16 PM, Umut Tezduyar Lindskog
wrote:
> What does this fix Jeff, could you please explain?
Here's the relevant part of a pkg-config file produced during make:
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include
Versus during configure:
prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Which disproportionately affects cross-compiling and similar build situations.
OpenWrt includes an equivalent change for kmod (which Lucas mentioned
as I've submitted it upstream), and without an upstream change will
have to carry one for systemd too.
Finally, a supporting appeal to authority: If you check GNOME-land,
practically all pkg-config files are generated at configure time. :-)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure
On Wed, Mar 11, 2015 at 5:04 AM, Jeff Waugh wrote: > Generate pkg-config files during configure as God (Havoc) intended. This fixes > all of systemd's pkg-config files when cross-compiling (and possibly other use > cases). Thoughts, feelings? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build: generate pkg-config files during configure
Generate pkg-config files during configure as God (Havoc) intended. This fixes all of systemd's pkg-config files when cross-compiling (and possibly other use cases). (Note: I might've missed some things to tidy up in Makefile.am, but not 100% sure.) Signed-off-by: Jeff Waugh --- Makefile.am | 3 --- configure.ac | 10 ++ 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index 3539e03..d2ebc81 100644 --- a/Makefile.am +++ b/Makefile.am @@ -6442,9 +6442,6 @@ man/%: man/%.in sysctl.d/%: sysctl.d/%.in $(SED_PROCESS) -%.pc: %.pc.in - $(SED_PROCESS) - %.conf: %.conf.in $(SED_PROCESS) diff --git a/configure.ac b/configure.ac index 29111f5..21b8008 100644 --- a/configure.ac +++ b/configure.ac @@ -1510,6 +1510,16 @@ AC_CONFIG_FILES([ docs/libudev/version.xml docs/gudev/Makefile docs/gudev/version.xml +src/libudev/libudev.pc +src/compat-libs/libsystemd-id128.pc +src/compat-libs/libsystemd-daemon.pc +src/compat-libs/libsystemd-login.pc +src/compat-libs/libsystemd-journal.pc +src/libsystemd/sd-id128/libsystemd-id128.pc +src/libsystemd/libsystemd.pc +src/udev/udev.pc +src/core/systemd.pc +src/gudev/gudev-1.0.pc ]) AC_OUTPUT -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A use case for staged startup
On Sun, Feb 22, 2015 at 6:04 PM, Andrei Borzenkov wrote: > Do you really need to fully overlay root? I.e. is it possible to just > (bind-)mount /etc, /var? /usr should be possible to retain read-only. > Once the upper layer of the overlayfs is JFFS2 (as intended), then it's more interesting to have all of / overlayed. > - and dutifully starts them all again once we're headed > towards multi-user.target > > > > That's a *lot* of noise in the startup process! > > But does it actually work? > Yes, it does! It's so awesome that all of this machinery is built in, and doesn't require reams of shell scripts. So, it totally works, it just has performance warts because of my weird use case. :-) I believe that if you just overlay /etc with probably new > default.target and run daemon-reload followed by isolate it /should/ > detect that some services are missing from new default.target and > continue. systemd can do all of that for me. The problem right now is that during the initrd stage, it has access to *all* of the system services, so dutifully starts them all up. Then isolates (kills them), switches root, and starts them all up again. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] A use case for staged startup
Hi all, Marko Hoyer recently brought up the concept of a staged startup [1] on this list. I have a specific use case for some form of staging, though I don't know if it meets Marko's definition or requirements! Perhaps systemd can handle this already, but let's see... So, I've been building a systemd package for OpenWrt [2] to test on my little VoCore coin-sized MIPS machine. (Stay with me, the weird part is over.) The root filesystem is a read-only squashfs blob stored on the VoCore's generous (!) 8MB of flash memory. During initial testing, I was happy to boot up into a read-only environment, bring up a few tmpfs mount points, and then keep mucking around with systemd. But it's time to get serious. And everyone knows that "serious" means having a writeable root filesystem. OpenWrt uses overlayfs with JFFS2 as the top layer. but I'm just using tmpfs for now. (For some values of "serious".) I wanted to make best use of systemd's built-in primitives, so here's what I've done: - default.target is symlinked to initrd.target in the read-only filesystem image - I've added some custom services to prepare all the mounts for the root switch (including one which changes the default.target symlink on the new, writeable root) Yes, I'm abusing systemd's idea of an initrd. Here's where it breaks down: - systemd dutifully starts all the services it knows about during the initrd.target run, because they're all right there on the read-only filesystem (and they fail a lot) - then systemd dutifully stops them all again to switch the root - and dutifully starts them all again once we're headed towards multi-user.target That's a *lot* of noise in the startup process! I did get the impression from the documentation that initrd.target was somehow special, but it makes complete sense that it's not. If I were using an initramfs, there wouldn't be any superfluous service files in the initramfs filesystem, and I'd be happy to know that systemd would behave *exactly* the same way it would elsewhere. One hacky idea I had to fix this: - Pull all of the systemd service symlinks out of the squashfs filesystem and store them in a tarball - Add specific symlinks to make the initrd stage works properly - In the pre-switch prepare service, unpack the tarball into the rw-mounted /sysroot Before anyone says it: No, using a real initramfs would be highly inappropriate. I do not want to store two copies of systemd and friends in 8MB of flash. It's hard enough with just the one! Is there an existing systemd solution to this problem? Is there a better way to go about it? Thanks, Jeff [1] http://lists.freedesktop.org/archives/systemd-devel/2015-January/027688.html [2] https://github.com/jdub/openwrt-systemd ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
