strncmp() could be used with size bigger then the size of the string,
because MAX was used instead of MIN.
If failing, print just the offending mount flag.
Whenever a message fails, mention the offending word, instead
of just giving the whole line. If one bad word causes just this
word to be rejected, print only the word. If one bad word causes
the whole line to be rejected, print the whole line too.
https://bugs.freedesktop.org/show_bug.cgi?id=56874
Sometimes it is better to see messages in full, and the existing
set of options didn't allow this easily. E.g. now
journalctl -f --full
will behave like
tail -f /var/log/messages
of yore.
Long option only for now, since small letters are becoming
scarce, and this doesn't feel like a capital-letter-option.
'-u' would be nice, and the above command would be spelled
journalctl -fu
> Kay:
udev is early boot without /var. /var is entirely taboo for udev.
This partially reverts commit ee623f0d0c
(moving hwdb.bin is reverted, but the uninstall hook and cosmetic
changes remain).
The path doesn't change in the standard configuration.
Also, give full path to the journalctl binary in the hook,
since it might be installed outside of $PATH.
Also, add uninstall hook to remove the binary catalog.
Some filesystem magics are too big to fit in 31 bits,
and are wrapped to negative. f_type is an int on 32 bits, so
it is signed, and we get a warning on comparison.
More specifically this adds a number of macros that resolve to
directories for udev rules, hwdb entries, tmpfiles and sysctl.
Thsi also includes three new macros for rebuilding the hwbd/catalog
index when a package drops in new files
This remove distro-specific support for early-boot SysV init scripts.
(And leaves support for normal SysV scripts untouched).
If distributions wish to continue to allow early-boot SysV scripts in
their distribution-specific way they should either maintain this patch
downstream manually, or write a generator for them, or simply ship all
those scripts with a .service wrapper.
We should always try to umount the old root dir if possible, instead of
overmounting it -- if that's possible.
The initial ("first") kernel rootfs can never be umounted, hence
for the usual nitrd case we never bothered using pivot_root() and
hence with fully unmounting it. However, fedup now tranisitions twice
during boot, and in that case it is highly desirable that the "second"
root dir is entirely unmounted when we switch to the "third". This patch
makes that possible.
The pivot_root() needs a directory in the "third" root dir, to move the
"second" root dir to. We use /mnt for that, under the assumption that
this directory is likely to exist, and is not itself a mount point.
If firmware file is not found in the file system, udev
terminates firmware loading. This is not the case if
firmware file exists in the file system but doesn't have
any data in it.
The hook would fail if preexisting journalctl doesn't support
--update-catalog. Also, the catalog would be updated before new
catalog files were installed. Both issues are fixed by moving to
INSTALL_DATA_HOOK instead of INSTALL_EXEC_HOOK, since the hook is now
executed after both journalctl and catalog files are installed.
As it turns out reboot() doesn't actually imply a file system sync, but
only a disk sync. Accordingly, readd explicit sync() invocations
immediately before we invoke reboot().
This is much less dramatic than it might sounds as we umount all
disks/read-only remount them anyway before going down.
I'm building systemd for an embedded system and we would prefer not having
to include the entire util-linux package just to get a libblkid whose
functionality we don't need.
The message catalog can be used to attach short help texts to log lines,
keyed by their MESSAGE_ID= fields. This is useful to help the
administrator understand the context and cause of a message, find
possible solutions and find further related documentation.
Since this is keyed off MESSAGE_ID= this will only work for native
journal messages.
The message catalog supports i18n, and is useful to augment english
language system messages with explanations in the local language.
This commit only includes short explanatory messages for a few example
message IDs, we'll add more complete documentation for the relevant
systemd messages later on.
On Thu, Nov 15, 2012 at 5:05 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> wrote:
> Something like this appeared with latest git:
>
> Nov 15 16:55:46 fedora-15 systemd-udevd[334]: worker [364] terminated by signal 11 (Segmentation fault)
> Nov 15 16:55:46 fedora-15 [387]: Process 364 (systemd-udevd) dumped core.
> Nov 15 16:55:46 fedora-15 systemd-udevd[334]: worker [364] failed while handling '/devices/virtual/net/lo'
> Nov 15 16:55:46 fedora-15 systemd-udevd[334]: worker [360] terminated by signal 11 (Segmentation fault)
> Nov 15 16:55:46 fedora-15 systemd-udevd[334]: worker [360] failed while handling '/devices/pci0000:00/0000:00:03.0/virtio0/net
> Nov 15 16:55:46 fedora-15 [389]: Process 360 (systemd-udevd) dumped core.
>
> Core was generated by usr/lib/systemd/systemd-udevd'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x0000000000423c87 in udev_hwdb_get_properties_list_entry (hwdb=0x0, modalias=0x7fffbcd155f0
If ListUnitFiles fails, or an OOM occurs, then dbus_message_unref()
will be called twice on "reply", causing systemd to crash. So remove
the call to dbus_message_unref(); it is unnecessary because of
the cleanup attribute on "reply".
[zj: modified to leave one dbus_message_unref() alone, per Colin
Walters' comment.]
A service that only sets the scheduling policy to round-robin
fails to be started. This is because the cpu_sched_priority is
initialized to 0 and is not adjusted when the policy is changed.
Clamp the cpu_sched_priority when the scheduler policy is set. Use
the current policy to validate the new priority.
Change the manual page to state that the given range only applies
to the real-time scheduling policies.
Add a testcase that verifies this change:
$ make test-sched-prio; ./test-sched-prio
[test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1
[test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0
[test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
Having unit(s) removed/not started, even if it solved the issue and allowed
to boot successfully, should still be considered an error, as something
clearly isn't right.
This patch elevates the log message from warning to error, and adds a status
message to make things more obvious.
