* python-systemd-reader:
python-systemd: rename Journal to Reader
build-sys: upload python documentation to freedesktop.org
systemd-python: add Journal class for reading journal
python: build html docs using sphinx
journalct: also print Python code in --new-id
python: utilize uuid.UUID in logging
python: add systemd.id128 module
... and 34 other commits
In short: python module systemd.id128 is added, and existing
systemd.journal gains a new class systemd.journal.Reader, which can be
used to iterate over journal entries. Documentation is provided, and
accessible under e.g.
pydoc3 systemd.journal.Reader
or
firefox http://www.freedesktop.org/software/systemd/man/python-systemd/
It seems inevitable that we'll also grow a writing interface,
and then it'll be cumbersome to have a "Journal" for reading,
and a "Writer" for writing.
Michal Schmidt [Wed, 27 Feb 2013 22:31:35 +0000 (23:31 +0100)]
core/transaction: replace a bare status_printf()
Like other status messages, this one too should not be printed
unconditionally, but it should take the manager state into account.
unit_status_printf() does that.
Michal Schmidt [Wed, 27 Feb 2013 21:54:14 +0000 (22:54 +0100)]
core: redefine unit_status_printf()
Take advantage of the fact that almost all callers want to pass unit
description as the last parameter. Those who don't can use the more
flexible manager_status_printf().
This introduces a new static list of known attributes and their special
semantics. This means that cgroup attribute values can now be
automatically translated from user to kernel notation for command line
set settings, too.
This also adds proper support for multi-line attributes.
This patch broke LOG_TARGET_AUTO, i.e. automatic selection of STDERR if
it is a TTY with a fallback on the journal and kmsg otherwise.
The general rule should probably be:
log_open() -- open the "best" possible logging channel according to
log_target configuration.
log_dispatch() -- don't open any log channels ever, with the exception
of kmsg since that has no drawbacks. And do this only on true errors of
the better log channel, not just when it wasn't opened.
Logs written by journald from the initramfs may be written to a
directory with the name created from a random machine-id. Afterwards,
when the root filesystem has been mounted and machine-id reinitalized,
logs will be written to the directory with a name created from the
proper machine-id. When logs are flushed to /var/log/journal,
everything is copied to one output directory.
When journalctl without '-m' is run after the logs have been flushed
to /var/log/journal, all messages are shown. However, when run while
logs are still in /run/log/journal, those stored under the random
machine-id will not be shown.
Make journalctl behave the same regardless whether persistent storage
has been enabled or not, and slurp all files from /run/log/journal
even without '-m'.
bash-completion: journalctl query by binary and device
The approach taken is different between the two:
- since there are many files in /usr, but messages appear
only for a tiny subset, the completion is performed
only for stuff shown by journalctl -F _EXE. This makes
sense because the list is already in proper form.
- since it is hard to convert _KERNEL_DEVICE to device
file name, simply all files in /dev/ are used as possible
completions.
Unfortunately zsh completion requires more work and is not
covered by this commit.
Dave Reisner [Sun, 24 Feb 2013 21:39:25 +0000 (16:39 -0500)]
build: remove explicit -shared in LDFLAGS
This doesn't need to be passed, as it's handled by libtool. Since the
default for autoconf is --disable-static, this change is effectively a
noop. It only matters if you pass --enable-static, in which case the
static libs for systemd libraries will actually be built.
Nitpicky, but this only affects systemd libs. The override for the
other libs remains since these libs are always loaded dynamically and
never compiled staticly.
Michal Schmidt [Fri, 22 Feb 2013 10:21:47 +0000 (11:21 +0100)]
systemctl: make shutdown operations use irreversible jobs
Occasionally people report problem with reboot/poweroff operations hanging in
the middle. One known cause is when a new transaction to start a unit is
enqueued while the shutdown is going on. The start of the unit conflicts with
the shutdown jobs, so they get cancelled. The failure case can be quite unpleasant,
becase getty and sshd may already be stopped.
Fix it by using irreversible jobs for shutdown (reboot/poweroff/...) actions.
This applies to commands like "reboot", "telinit 6", "systemctl reboot". Should
someone desire to use reversible jobs, they can say "systemctl start reboot.target".`
Michal Schmidt [Fri, 22 Feb 2013 10:21:37 +0000 (11:21 +0100)]
core, systemctl: add support for irreversible jobs
Add a new job mode: replace-irreversibly. Jobs enqueued using this mode
cannot be implicitly canceled by later enqueued conflicting jobs.
They can however still be canceled with an explicit "systemctl cancel"
call.
Michal Schmidt [Fri, 22 Feb 2013 08:56:16 +0000 (09:56 +0100)]
systemctl: make "systemctl default" use "isolate" job mode
"systemctl default" should behave identically to "telinit N" (where N is the
corresponding runlevel target number), therefore it should use isolate job mode
too.