Systemd can now pull and update container images from the Internet
plus.google.com
plus.google.com
Now, I'm just not so sure. The feature creep here is remarkable. Why on earth would systemd have anything to do with container management? Surely the 'docker' (or whatever) service which systemd is supposed to be managing should be doing this?
Another nail in the coffin of simple software that does one thing well.
Edit: s/docker/container management/
I'm with you here, at first I didn't understand the alarm but now I'm starting to see the danger of this trend.
And no, its not just for fun. RH is betting big on competing with Amazon and MS on cloud services. It would not surprise me if they are trying to get old RHEL server customers to move their servers onto the RH cloud with the switch to RHEL7.
systemd-import will grab Docker images from the internet, but I'm not sure it will do very much else. In other words, even if you adopt systemd's way of doing things in deployment, your developers are still using the docker command.
I'd believe you if Docker was some elegant, tiny, well-written tool, and systemd was a bloated mess of AbstractLinuxContainerFactoryImpls. But as far as I can tell, Docker is the thing that is neither simple nor does its one thing particularly well, and systemd implements this straightforwardly, because of all things you might want to do, booting a system is kind of easier if you're already an initsystem.
If systemd decides to implement WebGL or take on Sublime Text, let's talk, but these 200 lines of C don't seem like a reason to believe that we've moved away from simple software that does things well:
http://cgit.freedesktop.org/systemd/systemd/commit/src/impor...
http://cgit.freedesktop.org/systemd/systemd/commit/?id=72648...
> Now, I'm just not so sure. The feature creep here is remarkable.
Now you know why we had that acrimonious debate. This is precisely what was obvious right from the start.
Linux is Windows NT now, the only way to have a decent nix is to pick BSD.
>Now, I'm just not so sure.
You're starting to see what the original opponents feared a long time ago. It doesn't look like the feature creep is going to end any time soon, although I wonder if there will be a breaking point when even the fanboys say, "Hang on, this is a bit much..."
I installed it, ran it, and it immediately complained "not a systemd system" and refused to run. I've not looked into things further, but presumably systemd-nspawn requires that systemd be running, which was a surprise to me since systemd-nspawn calls itself "chroot on steroids", and chroot cares nothing about the init system.
If I remember correctly, systemd-nspawn uses cgroups (hence the "steroids" part of of "chroot on steroids").
On Linux, cgroups require a single manager for all cgroups (in this case systemd). This is not a systemd limitation; it is a requirement set by the Linux kernel[0].
In theory you could bring-your-own cgroup manager, but cgroups are nascent enough that trying to make a userland tool like systemd-nspan work with a completely pluggable cgroup manager would be a nightmare.
[0] http://www.freedesktop.org/wiki/Software/systemd/ControlGrou...
[1] https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt
http://man7.org/linux/man-pages/man2/unshare.2.html
http://man7.org/linux/man-pages/man2/clone.2.html
http://man7.org/linux/man-pages/man1/unshare.1.html
Loosely a "container" (in the LXC or Docker sense) is a combination of making new namespaces, which isolate the process tree from the rest of the system in various ways (filesystem, network, hostname as returned by "uname", etc.), and making a cgroup, which allows for process tracking and resource allocation.
This is terrible in both the "why is systemd doing this" and "it's just plain terrible software" sense.
That's only really an issue if someone ever turns this into a library and calls it from long-running code. As a command line utility the small amounts of memory that are leaked don't ammount to too much waste and everything gets reclaimed on exit.
This is Poetterings code after all, and he had his fingers in more than just command line utilities when it comes to systemd.
Writing this kind of software in C requires serious discipline and religious use of valgrind.
Being able to manage your allocation is a pretty good sign that a C programmer knows what he's doing. Relying on 'exit' to free your memory is backporting the web mentality to unix land, it just simply doesn't work that way. There is no different attitude when you write a long running daemon versus a utility program because for all you know your utility program code will be re-purposed to become part of a longer running daemon. So you write your code in as clean a manner as possible and balance your allocs/frees and make sure that you don't have any latent buffer overflows which you may not care about today because of the context your code executes in today because tomorrow that context of execution might change and then we're looking at yet another exploit.
A very fitting description of systemd as a whole.
> someone ... can't get memory leaks in a simple utility function right
because in a simple one-off utility it is right. Potterings didn't write these utilities to prove that he knew how to refcount.
At some point someone may come along and refactor this Docker import code into a library or something bigger.
The liberal use of completely unportable cleanup attributes shifts preventing memory leaks to the equally intractable problem of tracking stack allocated variable assignments, with an extra helping of double frees. I won't even comment on the show of horrors that is util:
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/...
I did just check again and realize that the single 'a' at the strndupa means it's using alloca, which is of course similarly unportable and has a whole slew of other problems, all of them intractable (did you pass that pointer to something that will use it later on? stack overflows?).
So hey, not a memory leak! Rejoice! It's just similarly broken.
Yeah, using alloca() (in any form, incl. VLA) isn't good style. At least it's bounded, since filename_is_valid() checks the length. But it uses FILENAME_MAX, which could be too large for the stack.
That's extremely unlikely.
This is definitely not pretty or good quality C code by any standard but let's not start spreading wrong information.
The stack overflowing because you use alloc for something of FILENAME_MAX length is just as likely as a malloc call running out of memory. After all, the heap grows 'up' and the stack grows 'down'. Other than that the mechanisms are roughly (very roughly, ok) identical.
The only time when you have to be extremely careful with alloca is when you use it in functions that might be called in a recursive manner. But then you're playing with fire anyway if you do not have hard upper bounds on the depth of your recursion.
Just because strdupa is not magical, does not mean it has its valid uses. In particular, the problem you allude to (knowing the scope of your memory) is something you would have to get right also if you use heap-allocated memory (unless you just leak everything of course, but I think we have established that that's not something we want to do).
Before jumping to conclusions, please verify what the code really does. C is a complex beast and what's "obvious" may not be such.
Relying on such niceties (as weird as it may seem, to a C programmer those are niceties) is what you gain if you are willing to trade them for portability (strndupa() is a GNU extension).
When the stack frame is unwound when the function returns the allocation is undone.
systemd is explicitly unportable (it uses glibc/gcc/linux-specific features liberally), this is not some sign of sloppy coding, but an explicit design decision as codified in the CODING_STYLE file.
Preventing memory leaks and tracking stack allocated variable assignment are not comparable at all. In the vast majority of cases the tracking of stack allocated variable assignments is entirely trivial. The problem with double freeing is also very hard to run into in practice. Getting a memory-leak when you don't use _cleanup_ is all too common on the other hand. Basically, as soon as there are more than one branch in your function you either have to use ugly goto's or remember to free on every branch, in practice either way you are just implementing the _cleanup_ macros manually all over the place (with all the bugs that implies).
Why don't you point to some code that would have been better without the use of the macros? It seems you think util.c is a god source of examples...
systemd-nspawn is a really fun thing to work with for developing early-init/daemons of various kinds, and this adds a bit more tools to that.
http://distrowatch.com/weekly.php?issue=20140908#qa
Here's to hoping that debian at least will reverse their position or that some group will fork it:
I don't like how systemd starts doing everything, people keep pointing to alternatives but when things start to depend on systemd for functioning the alternatives start to disappear one after another.
I'm also thinking that each new feature like this would widen the area for potential security vulnerabilities.
A feature apparently developed by Poettering's brother as a doctoral thesis...