Re: [systemd-devel] [RFC] the chopping block
On 11.02.2016 18:49, Lennart Poettering wrote:
> Again: this does not break systems with split off /var, as I tried to
> make very clear in my original mail. All that's needed is that the
> initrd mounts /var before handing off control to the main system.
I know that. Please don't assume that I misunderstood you just because
every systemd-basher during the last five years did the same thing. :-P
However, it *does* break systems which do not mount /var in their initrd
despite having /var (or a piece thereof) split off.
Such changes should have a "deprecated" phase between "works fine" and
"needs manual intervention".
The number of such systems is definitely not zero. In addition to
multi-boot machines with shared /var/{log,tmp,cache} sub-mounts, there's
the "somewhat-embedded system with root on SDHC card and /var on hard
disk / NFS / whatever" usecase. Some of these may not even *have* an initrd.
--
-- Matthias Urlichs
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] the chopping block
Hi, Lennart Poettering: > 5) Here's the controversial one I think: support for booting up >without /var. Meh. I have quite a few multi-boot systems with a common /var/log partition. Plus, unlike the other "spring cleaning" changes this would cause a boot failure after update. Thus: if you must, deprecate this now, but please leave the actual code alone until next spring. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am src/shared src/timedate
Hi, Kay Sievers: If the system's time zone changes, or the time is adjusted manually, we just re-arm all timers, and all should be fine. I see no need or use to support explicit triggers on the event of DST changes, the system or calendar time support just does not need them. So, in four hours (as I write this) there will be no 02:* hour for my 02:30 logfile cleanup job to run in. Does my system run it anyway? How do I change that? (I can see use cases for both options.) Same thing in the fall. An explicit trigger can do any number of things to help me prevent problems. What's even more important IMHO is the presence of a nice #OnDSTChange= remark in the spec template, because it teaches admins to actually *think* about what will happen when DST changes, instead of simply ignoring the problem and hoping that nothing 'interesting' will happen. DST changes more often than physically moving a machine to another timezone, for the vast majority of computers out there. Thus, frankly, it seems strange to advocate for support of the latter but not the former use case. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Linking containers
Hi, Lennart Poettering: Not sure I understand, but there's already --network-bridge= where you can configure a bridge that the container's veth link should be added to? The problem is (or was, last time I looked at that option) that --network-bridge= can only be used once, which is not sufficient. -- -- Matthias Urlichs ___ 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
Hi, Jeff Waugh: - 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 because, I assume, they're implied by default.target. So why don't you start the system with some different target that does just enough to switch roots and then calls systemctl start default.target? -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: use valid bus paths
Hi, Mantas Mikulėnas: Object path components must start with [A-Za-z_] (AFAIK). Also the value of 'p' is undefined if asprintf fails. IMHO you should not put two unrelated issues in one patch. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service.d/.conf files and multi-valued options
Hi, Dimitri John Ledkov: foo.service.d/bar.conf sets an option like Service/ExecStartPre that can be specified multiple times. Doesn't the manpage state that an empty entry clears the list? A snippet: [Unit] Wants= Does not remove want dependencies declared in the unit section in the unit file under /usr. Meh. Obviously that works only for some unit file entries, not for others. Time to impart more consistency? -- -- Matthias Urlichs signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to speed up journalctl -n foo ?
Hi, Ben Greear: real0m25.618s user0m2.361s sys 0m23.197s Something seems broken here. Do you have any old and/or inconsistent journal files lying around? [root@ath9k-f ~]# time tail -2000 /var/log/messages /tmp/foo.txt real 0m0.005s user 0m0.002s sys 0m0.003s To be fair, journalctl is of course slower if you don't filter for anything -- but the -nX case should be fast enough anyway. $ time journalctl -n 2000 /tmp/foo.txt real0m0.068s user0m0.056s sys 0m0.008s -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] List of unit states.
Hi, Lennart Poettering: And the various states so far have not been documented on purpose, since we want to have the liberty to still make alterations to the state machines. And I am not convinced the time has come yet to set this in stone and document it. You might document it but add a fat this list may change whenever systemd gets updated, so don't depend on it too much warning. Then again, frankly, to me the LOAD/ACTIVE/SUB states are self-explaining enough that I didn't yet miss any documentation of them … -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] loopback setup in unprivileged containers
Hi,
Tom Gundersen:
On Sun, Dec 28, 2014 at 6:18 PM, Stéphane Graber
stephane.gra...@canonical.com wrote:
My host system doesn't have nspawn so I can't easily test it this way,
but it was my understanding that nspawn didn't support user namespaces
and uid/gid mappings which is what I'm working with here.
Indeed, that is not supported by nspawn (which explains why I cannot
reproduce). I was able to reproduce using the userns_child_exec test
program from [0], so I'll take a look.
Hmm. IMHO it would be reasonable to add a mapping option
(--{user,group}map=inside:outside[:length]) to nspawn.
--
-- Matthias Urlichs
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] loopback setup in unprivileged containers
Hi, Lennart Poettering: I am open to adding support for this, but I think the allocation of the UID ranges should really happen automatically, and not be something the admin has to manually assign. Which means we'd enter dynamic UID allocation terroritory, and that opens a huge can of worms... Both. My Debian autobuilder, for instance, needs static UIDs. Frankly, I also manage a bunch of other VMs with just systemd because -nspawn does all I need (other than UID mapping … oh yes, and the ability to attach to more than one bridge interface) and I don't want to bother with yet another tool. :-P Fortunately we have 32-bit UIDs these days. So for automatic allocation I'd just sequentially number the machines and give each of them a 2048-UID chunk (with the top couple of addresses mapped to 6553x for nobody:nogroup) above 65536. Problem solved. However, this is not a problem for -nspawn itself: if I want to do auto-allocation, I can easily write a shallow wrapper (in whatever script language I want) which calculates the appropriate options and then exec()s nspawn. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix install location of systemd.pc
Hi, Mike Gilbert: libdir=/usr/lib/x86_64-linux-gnu which isn't architecture agnostic and thus not suitable for /usr/share/. From Lennart's commit message, it seems like this was done intentionally. It still doesn't work on a multi-arch system. :-P -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateDevices=true blocks use of ttys?
Hi, Alison Chaiken: Isn't /dev/tty0 a pseudo TTY? It's an alias to the current real TTY, which is not exactly the same thing. IMHO PrivateDevices=yes is supposed to make sure that this job cannot mess up any real device. Writing junk to /dev/tty0 can mess up my console quite easily. Therefore, blocking /dev/tty0 is correct. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to write two .mount units for the same directory?
Hi, 崔灏 (CUI Hao): I want to write 2 mount unit to mount the same directory. When the first failed to mount, then the second is called via OnFailure= setting. I'd handle this by starting a shell script which simply tries the first mount, and then does the backup mount if the first fails. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v218
Hi, Colin Guthrie: What's the argument for including /usr/local in all this stuff? Feels wrong to me. +ME_TOO. /usr/local frequently has wider permissions than reasonable for something that can affect system startup. I can think of one argument in favor of this -- you can modify the system default that way, without touching /etc, so this would add local modifications to an image which you then use for system initialization. However, you can do the same thing by adding appropriate *.conf files to /usr/lib/systemd/**. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
Hi, Jóhann B. Guðmundsson: After I explained it to them they said why not just call it [BridgeFDB] ... +1 -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 2 commits - src/core src/journal-remote src/network
Hi, Zbigniew Jędrzejewski-Szmek: wrap a few *_FOREACH macros in curly braces cppcheck is full of errors anyway. I don't think we should make the code less pretty just to satisfy a checker, and a rarely used one. While you may be right about cppcheck, IMHO it's good style to wrap all multi-line subordinates in curlies on general principle. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build error with 218 - undefined reference to `__start_BUS_ERROR_MAP'
Hi, Lennart: The idea is that any .c file linked into a binary can define additional maps, and we collect them all simply by iterating through __start_BUS_ERROR_MAP to __stop_BUS_ERROR_MAP. Unless there are none of these entries. Umut: Does the cross compiling somehow not include any data that are in section BUS_ERROR_MAP? If that's actually intended, this should fix it: char dummy_bus_error_map[0] __attribute__ ((__section__(BUS_ERROR_MAP))); -- -- Matthias Urlichs signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
