BusyBox Drops Systemd Support

[jb.1234abcd]

Let me quote some users:

"True, systemd consists of 69 [edit: 119] binaries. But they are so tightly coupled that to my knowledge nobody so far was able to provide a fully compatible alternative implementation for any of them. Besides, since the APIs internal to those systemd binaries are not only undocumented but also constantly changing, providing a compatible alternative implementation means aiming for a moving target.
Even if LP holds the 69 [edit: 119] binaries as proof that systemd isn't monolithic, to me that's BS. The strong coupling is what makes for a monolith."

" ... the problem seems to be that the systemd people aren't coding to interfaces. If they were, then dependencies wouldn't be on specific code, i.e. the implementations."

What outside devs need are stable external interfaces.
Many devs see it as a serious problem for them. They would have to "import" systemd's design, for good or bad.
Even some systemd supporters see it and ask for reconsideration of how systemd is developed, packaged, and offered to outside users/devs/integrators/etc.
Just imagine the BusyBox maintainers confronting integration of systemd into their limited and compressed environment.

[pal666]

denys vlasenko is not willing to play nice with the rest of the world
world is not going to wait for him

[pal666]

Unfortunately, no one has worked much on / on NFS support. I suggest opening an issue.

who cares when systemd is working perfeclty?

That said, how did you put systemd into your initramfs? As far as I know, there is no established way of doing that. Dracut does not, although some people might think it does in Fedora et al.

and such drug abusers tried to redo systemd lol. what is located in fedora's /usr/lib/dracut/modules.d/98systemd/ ?

[pal666]

Earlier this year, I discovered none of the Redhat's employees at LinuxCon North America there actually understood systemd

maybe that is because contrary to your crazy beliefs only tiny fraction of redhat employees is working on systemd?

[pal666]

with systemd being also a Redhat project, we can predict some shit hitting the fan, don't we?

systemd is not a redhat project, but shit is going to hit the fan neverseless

[SystemCrasher]

Don't forget hotplug stuff. Many routers nowadays work as audio/file/print servers. I still think the main reason for not having systemd there is the persistent space, not RAM.

Actually, both. If you have something like 4-8Mb ROM, you would not even have enough space for drivers, so audio, print and so on would be very limited. And I wish you luck to start full-blown CUPS on router. And without CUPS printing support is very limited, to say the least. But RAM is also an issue. Low end routers come with 32Mb RAM, and still, the more RAM you have, the larger conntrack table you can afford. And it is essentially a tradeoff between number of tracked sessions CONNTRACK can handle and timeout value, where it kills off idle connection, potentially breaking something like SSH session which you abandoned for some mere 5 minutes just to figure out it has been ripped off as dead due to lack of traffic. If conntrack table overflows and you face out of RAM, utterly bad things happen, not even OOM killer can get memory back from kernel. If you limit conntrack size, other bad things happen when you launch torrent or whatever and soon figure out you can't do new connections or old connections are falling apart, depends on what you prefer (in terms of timeouts and numbers of sessions).

And so wasting 4 of 32Mb for systemd isn't good idea. If one got extra 4M RAM, they are really better to adjust conntrack to more pleasant settings, etc. So you can afford longer timeouts and/or more connections on the very same hardware. Since you're not going to manage small router stuff on daily basis, it could be okay to have crippled/limited system tools if it improves other areas a lot.

Though to tell it honestly, these days one can just buy something like dual core 1GHz ARM CPU thing, with gigabit switch on bord and some wi-fi for some mere $50 or so, if they want something more like a microserver, router and NAS at once. Just search something like aliexpress for stuff like Banana Pi router. Though it is better in being general purpose powerhouse than being superb in wireless.

Even some 802.11ac routers have only 8 MB of ROM. It's not much.

Well, compared to 4Mb, 8Mb is quite okay :P

You might need 1 MB just for the firmware,

Best achievement I've seen so far: LZMA compressed u-boot which fits one 64Kb sector of flash. Yet, it supports Ethernet and actually can display web interface. Making system recovery user friendly. And those who waste 1M on boot should either show us some groundbreaking features in their boot loader, or go fire their insane monkeys and hire some real system engineers.

3 megs for the kernel.

Actually, 3 megs for kernel is quite a lot and decompressed 3 Mb kernel will be pretty large in RAM. Especially if compressed with XZ, where it would be something like 10+Mb of kernel code and data reduced down to 3Mb.

The hardware might reserve 1/2 megs. You really don't have room for systemd.

Well, some routers come with NAND these days...

Flash space should be cheap nowadays. Around $0.25 to $1.00 per gigabyte (NAND). NAND is good enough if you have enough of it. I can't see why the routers have less than a meg of flash. They already have 128-512 megs of RAM ($70 to $200 routers).

NAND is rather troublesome thing. Go read something like Linux MTD mailing list to get idea what you can face. NOR flash is far more simple thing and CPU can boot from it directly (from parrallel NOR) or using very simple hardware automation or really tiny on-chip ROM code (for SPI NOR). NANDs are orders of magnitude more complicated things. Yet, some routers actually come with NAND flash these days. But booting from NAND is somewhat like an arcane art. Some SoC's can do it but there're many limitations and catches involved. So if you're about to break-n-enter and have fun with system, NAND could prove to be quite a major source of ... headache.

[ryao]

who cares when systemd is working perfeclty?

systemd has plenty of portability issues and the systemd developers reject patches to fix them. It also replaces stable documented interfaces with internal undocumented ones that have no stability guarantees. It might work for certain use cases, but given its developers hostility to use cases outside of Fedora/RHEL, it is not a general solution.

and such drug abusers tried to redo systemd lol. what is located in fedora's /usr/lib/dracut/modules.d/98systemd/ ?

Interesting. I had been unaware this was added. However, dracut is fully capable of operating without it.

maybe that is because contrary to your crazy beliefs only tiny fraction of redhat employees is working on systemd?

I never thought otherwise, but I did think that Redhat's representatives would be familiar with how to do things with systemd's logs. Knowing that is sort of important.

That said, I suggest avoiding strawmans like "because contrary to your crazy beliefs...". It makes it difficult to take you seriously.

[ryao]

If you want to use cluster file systems as ocfs2, then you definitively need to cleanly unmount them, otherwise bad things happen. Problem : in conjunction with network block devices as e.g. NBD or iscsi, where you have a daemon running, the default behaviour of openrc : "killing all processes and then unmounting the fs" does not work, as unmounting hangs as soon as the process controlling/feeding the block device is dead. Thus, you have to return to initramfs to handle disassembling the device. Systemd on gentoo does this, if it finds your initramfs - AFAIR it looks for certain names in /boot and then executes some shell script in the initramfs. I don't use ocfs2 any more, so this information is solely from memory.

As interested pointed out in the other thread, the documentation on how systemd+dracut interact on shutdown is here:

https://github.com/haraldh/dracut/bl...ut-on-shutdown

According to it, systemd+dracut does shutdown by "killing all processes and then unmounting the fs" too. The only thing different is that it pivots into an initramfs environemnt to try to finalize things. However, it will only get there by systemd doing a timeout on the hung umount that you said will occur when the process controlling/feeding the block device is dead.

As for systemd on Gentoo doing that, it does not actually. What happens is that dracut will leave a file around for systemd to find to tell it to go back into the dracut environment after it is ready to finish shutdown when a dracut driver indicates a need for that. If the dracut drivers do not indicate that it is needed, it is not done. That is how dracut+systemd work everywhere.

[oleid]

As interested pointed out in the other thread, the documentation on how systemd+dracut interact on shutdown is here:

I don't know about dracut, since I didn't end up using it. It seemed way to complicated and undocumented when it comes to NFS stuff.

mkinitcpio does the following (quoting https://lists.archlinux.org/pipermai...er/025742.html)

The new mkinitcpio [...] in testing contains a new feature that automatically generates an "initramfs" on shutdown. systemd will pivot to this image on shutdown. All it does is re-run systemd-shutdown in a ramdisk, thus allowing a proper umount of / and proper shutdown of ALL loop and device mapper devices.

This is the service, which is called on shutdown:
http://code.metager.de/source/xref/a...-ramfs.service

And this is from the documentation talking about systemd initrd interaction (http://www.freedesktop.org/wiki/Soft...itrdInterface/)

• If the executable /run/initramfs/shutdown exists systemd will use it to jump back into the initrd on shutdown. /run/initramfs should be a usable initrd environment to which systemd will pivot back and the "shutdown" executable in it should be able to detach all complex storage that for example was needed to mount the root file system. It's the job of the initrd to set up this directory and executable in the right way so that this works correctly. The shutdown binary is invoked with the shutdown verb as argv[1], optionally followed (in argv[2], argv[3], ...) by systemd's original command line options, for example --log-level= and similar.
• Storage daemons run from the initrd should follow the the guide on systemd and Storage Daemons for the Root File System to survive properly from the boot initrd all the way to the point where systemd jumps back into the initrd for shutdown. One last clarification: we use the term initrd very generically here describing any kind of early boot file system, regardless whether that might be implemented as an actual ramdisk, ramfs or tmpfs. We recommend using initrd in this sense as a term that is unrelated to the actual backing technologies used.

So, I don't know what dracut does, but it is possible to start a daemon in the boot-initramfs and only kill it in the shutdown-initramfs. In the worst case, you've to hack the initramfs yourself

[interested]

systemd has plenty of portability issues

Only to entirely different operating systems, like BSD, and there are good technical reasons for being Linux-only compatible.

And the whole point is irrelevant anyway since systemd is LGPL, and the BSD distros will never allow core components that can't be close sourced since their paymasters request this. This is why BSD systematically have been killing of all GPL code in their core for years now.

and the systemd developers reject patches to fix them.

And for very good technical reasons too. Placing a "turd" patch into systemd that disables security measures just because some non-conformant libc implementation can't be bothered to implement them, should of course not be allowed. The entire OpenSSL "Heartbleed" bug was caused be exactly such a turd patch from a close source Unix that couldn't be bothered to update its libraries and therefore turned off some security measure.

It is the small, non-standard libc implementations that need to be patched with glibc extensions that systemd needs, not the other way around.

It also replaces stable documented interfaces with internal undocumented ones that have no stability guarantees.

Something that is completely without any consequences for non-systemd distros that have their own solutions.

This is only a problem if a non-systemd distro wants to rip out some random piece of systemd and use it outside its intended environment instead of just coding their own version. Really a kind of self-inflicted problem by people feeling entitled to the systemd code somehow.

systemd have plenty of stable and just as important, well documented interfaces:
http://www.freedesktop.org/wiki/Soft...tabilityChart/

Many things from that chart have been implemented independently, even on BSD.