CHANGES WITH 187: * The journal and id128 C APIs are now fully documented as man pages. * Extra safety checks have been added when transitioning from the initial RAM disk to the main system to avoid accidental data loss. * /etc/crypttab entrie now understand the new keyfile-offset= option. * systemctl -t can now be used to filter by unit load state. * The journal C API gained the new sd_journal_wait() call to make writing synchronous journal clients easier. * journalctl gained the new -D switch to show journals from a specific directory. * journalctl now displays a special marker between log messages of two different boots. * The journal is now explicitly flushed to /var via a service systemd-journal-flush.service, rather than implicitly simply by seeing /var/log/journal to be writable. * journalctl (and the journal C APIs) can now match for much more complex expressions, with alternatives and disjunctions. * When transitioning from the initial RAM disk to the main system we will now kill all processes in a killing spree to ensure no processes stay around by accident. * Three new specifiers may be used in unit files: %u, %h, %s resolve to the user name, user home directory resp. user shell. This is useful for running systemd user instances. * We now automatically rotate journal files if their data object hash table gets a fill level > 75%. We also size the hash table based on the configured maximum file size. This together should lower hash collisions drastically and thus speed things up a bit. * journalctl gained the new "--header" switch to introspect header data of journal files. * A new setting SystemCallFilters= has been added to services which may be used to apply blacklists or whitelists to system calls. This is based on SECCOMP Mode 2 of Linux 3.5. * nspawn gained a new --link-journal= switch (and quicker: -j) to link the container journal with the host. This makes it very easy to centralize log viewing on the host for all guests while still keeping the journal files separated. * Many bugfixes and optimizations
Yeah, +me they have done a lot, possibly the change rate of their git exceeded that of mainline linux. But: Why is their a systemd package after they merged with udev. Systemd should be just a USE flag of udev package. That would be pure Gentoo logic despite opposite naming of upstream ...
(In reply to comment #1) > Yeah, +me > they have done a lot, possibly the change rate of their git exceeded that of > mainline linux. > > But: > Why is their a systemd package after they merged with udev. Systemd should > be just a USE flag of udev package. That would be pure Gentoo logic despite > opposite naming of upstream ... There's no such thing as 'pure Gentoo logic'. Gentoo always tried to follow upstream closely, and I follow that policy.
is there a plan how to handle systemd vs udev? only found an older unresolved thread: http://www.gossamer-threads.com/lists/gentoo/dev/256809
(In reply to comment #3) > is there a plan how to handle systemd vs udev? > > only found an older unresolved thread: > > http://www.gossamer-threads.com/lists/gentoo/dev/256809 They will still be separate packages, with systemd providing its own udev install guaranteed to be systemd-compatible, and udev providing guarantee of Gentoo-compatible install.
Please bump systemd-188
(In reply to comment #5) > Please bump systemd-188 Will do when situation with udev is clear.
-188 in tree and unmasked.
(In reply to comment #7) > -188 in tree and unmasked. Great job, Michał! Thank you very much for your hard work. I've been following the struggle with systemd developers to get systemd and udev to build and install separately in a proper manner and I see they're not paying any attention to this.
