| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Bug introduced in 984f1b1d1b. The state was flipped later,
but the enable/disable routine made use of the state to decide
what to do.
context_enable_ntp() and context_start_ntp() now get the desired
state directly, so the Context parameter can be removed.
|
|
We'd use the generic check for disable, and a unit-file-specific one for enable.
Use the more specific one both ways.
systemd[1]: SELinux access check scon=system_u:system_r:systemd_timedated_t:s0 tcon=system_u:system_r:init_t:s0 tclass=system perm=disable path=(null) cmdline=/usr/lib/systemd/systemd-timedated: -13
systemd[1]: SELinux access check scon=system_u:system_r:systemd_timedated_t:s0 tcon=system_u:object_r:systemd_unit_file_t:s0 tclass=service perm=enable path=/usr/lib/systemd/system/systemd-timesyncd.service cmdline=/usr/lib/systemd/systemd-timedated: -13
https://bugzilla.redhat.com/show_bug.cgi?id=1014315
|
|
timedated would set the internal status before calling out to systemd to do
the actual change. When the operation was refused because of a SELinux denial,
the state kept in timedated would get out of sync, and the second call from
timedatectl would appear to succeed.
https://bugzilla.redhat.com/show_bug.cgi?id=1014315
|
|
|
|
A failed priority is not something worth stopping boot over. Most people
have only one swap device, in which case priority is irrelevant, and even
if there is more than one swap device, they are all usable, and ignoring the
priority field should only result in some loss of performance.
The kernel will report the priority as -1 if not set, so it's easy for
people to make this mistake.
https://bugzilla.redhat.com/show_bug.cgi?id=1204336
|
|
|
|
All callers look at the return value anyway.
|
|
We should never access parents, as the sysfs hierarchy is in no way
stable. Use KERNELS== etc. to match on a parent, then access it via
$attr{} (which accesses the matching device, not the current device).
|
|
We match on the evdev node, but only the parent has a "name" attribute.
Use $attr{device/name} to access it.
This is borked since 2013, I wonder how that ever worked? Maybe this will
suddenly fix all the DMI-based key detections.
Thanks to Peter Hutterer for catching this!
|
|
|
|
Allow systemd-tmpfiles to set the file/directory attributes, like
chattr(1) does. Two more commands are added: 'H' and 'h' to set the
attributes, recursively and not.
|
|
Add change_attr_fd() function to modify the file/directory attribute.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=89598
|
|
This makes it easier to apply stable branch patches on top of the
release tarball.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=89684
|
|
cur and max were changed to size_t in ac6e2f0dfc2e800f01c79ecea2b811914110a7b9
update the format accordingly.
|
|
|
|
We always return NULL/invalid-object from destructors, fix strv_free() to
do the same.
|
|
We already call parse_argv() from main(), don't call it here again.
|
|
This allows set_action(), read_uevent_file() and read_db() to be made internal to libudev.
|
|
Create minimal image which runs systemd
FROM rhel7.1
RUN yum install -y /usr/bin/ps
ENV container docker
CMD [ "/usr/sbin/init" ]
When you run the container without -t, the process
/sbin/agetty --noclear --keep-baud console 115200 38400 9600
is not happy and checking the journal in the container, there is a stream of
Mar 13 04:50:15 11bf07f59fff agetty[66]: /dev/console: No such file or directory
Mar 13 04:50:25 11bf07f59fff systemd[1]: console-getty.service holdoff time over, scheduling restart.
Mar 13 04:50:25 11bf07f59fff systemd[1]: Stopping Console Getty...
Mar 13 04:50:25 11bf07f59fff systemd[1]: Starting Console Getty...
Mar 13 04:50:25 11bf07f59fff systemd[1]: Started Console Getty.
Mar 13 04:50:25 11bf07f59fff agetty[67]: /dev/console: No such file or directory
Mar 13 04:50:35 11bf07f59fff systemd[1]: console-getty.service holdoff time over, scheduling restart.
Mar 13 04:50:35 11bf07f59fff systemd[1]: Stopping Console Getty...
Mar 13 04:50:35 11bf07f59fff systemd[1]: Starting Console Getty...
Mar 13 04:50:35 11bf07f59fff systemd[1]: Started Console Getty.
Mar 13 04:50:35 11bf07f59fff agetty[74]: /dev/console: No such file or directory
Mar 13 04:50:45 11bf07f59fff systemd[1]: console-getty.service holdoff time over, scheduling restart.
Mar 13 04:50:45 11bf07f59fff systemd[1]: Stopping Console Getty...
Mar 13 04:50:45 11bf07f59fff systemd[1]: Starting Console Getty...
|
|
The comparison function we use for qsorting paths is overly indifferent.
Consider these 3 paths for sorting:
/foo
/bar
/foo/foo
qsort() may compare:
"/foo" with "/bar" => 0, indifference
"/bar" with "/foo/foo" => 0, indifference
and assume transitively that "/foo" and "/foo/foo" are also indifferent.
But this is wrong, we want "/foo" sorted before "/foo/foo".
The comparison function must be transitive.
Use path_compare(), which behaves properly.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1184016
|
|
... and make path_equal() a simple wrapper around it.
|
|
|
|
|
|
|
|
|
|
This will be used by fsckd. This reverts part of
031886edfc6e96ab778c241035a8d00fb0de99d3.
|
|
Even if plymouth is running, it might have not displayed the splash yet,
so we'll see a few lines on fbcon when we should have otherwise had
nothing.
Plymouth integration was added to systemd in commit
6faa11140bf776cdaeb8d22d01816e6e48296971. That same day, Plymouth got
systemd integration [0]. As such, the Plymouth integration has always
been obsolete, and was probably only for older Plymouth's. But I can't
imagine anybody running a Plymouth from 2011 with a systemd from 2015.
Remove the Plymouth/systemd integration, and let Plymouth's code tell
systemd to print the details.
[0] http://cgit.freedesktop.org/plymouth/commit/?id=537c16422cd49f1beeaab1ad39846a00018faec1
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Cc: Daniel Drake <dsd@endlessm.com>
Cc: Ray Strode <rstrode@redhat.com>
|
|
This reverts commit ba76ee29bc02879fb42c048132af8889b00220d5. As it turns
out, we need to match on driver=atkbd to not load the fixups on any
plugged USB devices.
That is, whenever you use "name:<name>:dmi:<dmi>" style matches, you
better provide a name or you're screwing things up.
|
|
Commit 628c89c introduced the "tentative" device state, which caused
devices to go from "plugged" to "tentative" on a remove uevent. This
breaks the cleanup of stale mounts (see commit 3b48ce4), as that only
applies to "dead" devices.
The "tentative" state only really makes sense on adding a device when
we don't know where it was coming from (i. e. not from udev). But when
we get a device removal from udev we definitively know that it's gone,
so change the device state back to "dead" as before 628c89c.
|
|
|
|
Currently, we always run
hwdb 'keyboard:name:$attr{name}:$attr{[dmi/id]modalias}'
as last step to match keyboards. Therefore, if nothing else matched so
far, we still try the device-name+dmi combination.
However, we have a special atkbd rule which is only run for atkbd as:
hwdb 'keyboard:$attr{[dmi/id]modalias}'
This is redundant, as we already pass the same information to hwdb in the
last fallback step.
This patch converts the hwdb "keyboard:dmi:*" matches to
"keyboard:name:*:dmi:*" matches and drops the redundant rule.
|
|
The 60-keyboard rules are already guared by KERNEL!="event*" bail-outs,
therefore, KERNELS="input*" is always true. Drop it!
|
|
Drop the restriction not to match on bluetooth devices. They are supported
just fine!
|
|
There is no reason to match on usb-modaliases, if we can use the
input-modalias to achieve the same. This commit changes the
keyboard-lookups to not be restricted to USB, but pass all modaliases to
the hwdb. Furthermore, we convert all usb:* matches to input:* matches,
thus getting rid of any ambiguity if multiple usb devices are chained (or
a bluetooth device / etc. is on top).
Note that legacy keyboard:usb:* matches are still supported, but
deprecated. If possible, please use keyboard:input:* matches instead.
This is a required step to make other input devices work with
60-keyboard.hwdb. Other bus-types are often chained on usb and we want to
avoid any ambiguity here if we incorrectly match on a USB hub.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=89582
|
|
|
|
If we don't check the error of the child process, systemd-vconsole-setup
would exit with 0 even if it could not really setup the console.
For a simple test, move loadkeys elsewhere and execute
systemd-vconsole-setup:
[root@localhost ~]# strace -f -e execve /usr/lib/systemd/systemd-vconsole-setup
execve("/usr/lib/systemd/systemd-vconsole-setup", ["/usr/lib/systemd/systemd-vconsol"...], [/* 15 vars */]) = 0
Process 171 attached
[pid 171] execve("/usr/bin/loadkeys", ["/usr/bin/loadkeys", "-q", "-C", "/dev/tty0", "br-abnt2"], [/* 15 vars */]) = -1 ENOENT (No such file or directory)
[pid 171] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=171, si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
+++ exited with 0 +++
Note that loadkeys returned 1 while systemd-vconsole-setup return 0.
Since the font and keyboard setup are already serialized, refactor the
code a little bit so the functions do the wait by themselves. One change
in behavior in this patch is that we don't return early, but we do try
to setup the keyboard even if the font load failed.
|
|
Despite having the internal logic in place to enable/disable using NTP
servers provided by DHCP the network config didn't expose the option.
|
|
|
|
Also use our own mkostemp wrapper, which tries to use O_TMPFILE.
|
|
It allocates memory, so it can fail.
CID #1237527.
|
|
CID #1237546.
|
|
Mar 13 19:48:28 adam.happyassassin.net systemd[1]: Collecting (null)
Mar 13 19:48:28 adam.happyassassin.net systemd[1]: Collecting (null)
Mar 13 19:48:28 adam.happyassassin.net systemd[1]: Collecting (null)
Mar 13 19:48:28 adam.happyassassin.net systemd[1]: Collecting (null)
Mar 13 19:48:28 adam.happyassassin.net systemd[1]: Collecting (null)
Mar 13 19:48:28 adam.happyassassin.net systemd[1]: Collecting (null)
Mar 13 19:48:28 adam.happyassassin.net systemd[1]: Collecting (null)
|
|
|
|
On Fri, Mar 13, 2015 at 8:25 PM, Michael Marineau <michael.marineau@coreos.com> wrote:
> Currently systemd-timesyncd.service includes
> ConditionVirtualization=no, disabling it in both containers and
> virtual machines. Each VM platform tends to deal with or ignore the
> time problem in their own special ways, KVM/QEMU has the kernel time
> source kvm-clock, Xen has had different schemes over the years, VMware
> expects a userspace daemon sync the clock, and other platforms are
> content to drift with the wind as far as I can tell.
>
> I don't know of a robust way to know if a platform needs a little
> extra help from userspace to keep the clock sane or not but it seems
> generally safer to try than to risk drifting. Does anyone know of a
> reason to leave timesyncd off by default? Otherwise switching to
> ConditionVirtualization=!container should be reasonable.
|
|
Audit messages would be displayed as "unknown[1]".
Also specify AUTH as facility... This seems to be the closest match
(/* security/authorization messages */).
|
|
|
