Daniel Mack [Fri, 24 Jul 2015 11:49:11 +0000 (13:49 +0200)]
tree-wide: do not use _cleanup_free_ on const pointers
free() cannot be used with const pointers. However, our _cleanup_free_
handler features cast logic that hides that qualifier, so we don't get a
warning.
David Herrmann [Fri, 24 Jul 2015 10:37:12 +0000 (12:37 +0200)]
sd-bus: don't treat KDBUS_ITEM_TIMESTAMP as unknown item
In bus_kernel_translate_message(), we print a DEBUG message on unknown
items. But right now, we also print this message for KDBUS_ITEM_TIMESTAMP
despite parsing it properly. Fix this!
journal: uppercase first character in verify error messages
In the english language the first character of a sentence is supposed to
be uppercase. Let's make sure this also applies to the journal
verification error messages.
journal: avoid mapping empty data and field hash tables
When a new journal file is created we write the header first, then sync
and only then create the data and field hash tables in them. That means
to other processes it might appear that the files have a valid header
but not data and field hash tables. Our reader code should be able to
deal with this.
With this change we'll not map the two hash tables right-away after
opening a file for reading anymore (because that will of course fail if
the objects are missing), but delay this until the first time we access
them. On top of that, when we want to look something up in the hash
tables and we notice they aren't initialized yet, we consider them
empty.
This improves handling of some journal files reported in #487.
process: return ESRCH when a PID is not valid anymore
so far, when we read something from /proc/$PID we would pass on the
ENOENT from the kernel as error, if the process was missing. With this
change we systematically convert this to ESRCH, which is the more
appropriate error code, and what all the other glibc/syscalls like
kill() use.
All code that calls these functions should be fine with this change. In
fact, one invocation of get_process_exe() in bus-creds.c already assumed
ESRCH would be returned if a process is missing, and this assumption is
now validated after the change.
Christian Hesse [Thu, 23 Jul 2015 19:18:36 +0000 (21:18 +0200)]
virt: handle Virtualbox 5.0 with kvm hypervisor
Virtualbox 5.0 now supports kvm hypervisor. In this case cpuid
identidies as "kvm", which breaks units depending on
ConditionVirtualization=oracle.
So return "oracle" even with kvm hypervisor.
Tom Gundersen [Thu, 23 Jul 2015 11:13:43 +0000 (13:13 +0200)]
resolved: rr - don't read past end of RR when parsing NSEC(3)
We can never read past the end of the packet, so this seems impossible
to exploit, but let's error out early as reading past the end of the
current RR is clearly an error.
Tom Gundersen [Thu, 23 Jul 2015 10:57:58 +0000 (12:57 +0200)]
resolved: packet - fail on invalid zero-length data
Most blobs (keys, signatures, ...) should have a specific size given by
the relevant algorithm. However, as we don't use/verify the algorithms
yet, let's just ensure that we don't read out zero-length data in cases
where this does not make sense.
The only exceptions, where zero-length data is allowed are in the NSEC3
salt field, and the generic data (which we don't know anything about,
so better not make any assumptions).
No need to actually reset the bitmap, we can just truncate it back zero
size. That not only makes bitmap_clear() quicker, but also subsequent
bitmap_isclear().
Let's make dns_packet_read_public_key() more generic by renaming it to
dns_packet_read_memdup() (which more accurately describes what it
does...). Then, patch all cases where we memdup() RR data to use this
new call.
This specifically checks for zero-length objects, and handles them
gracefully. It will set zero length payload fields as a result.
Special care should be taken to ensure that any code using this call
can handle the returned allocated field to be NULL if the size is
specified as 0!
Mike Gilbert [Thu, 23 Jul 2015 02:34:57 +0000 (22:34 -0400)]
nspawn: Don't pass uid mount option for devpts
Mounting devpts with a uid breaks pty allocation with recent glibc
versions, which expect that the kernel will set the correct owner for
user-allocated ptys.
The kernel seems to be smart enough to use the correct uid for root when
we switch to a user namespace.
tmpfiles: downgrade errors when a file system does not support file attributes
This downgrades errors from setting file attributes via tmpfiles to
warnings and makes them non-fatal.
Also, as a special case, if a file system does not support file
attributes at all, then the message is downgraded to debug, so that it
is not seen at all.
With this change reiserfs should not see any messages at all anymore
(since it apparently does not implement file attributes at all), but XFS
will still get a warning but no failure. The warning is something the
XFS kernel folks should fix though, by adjusting their file attributes
behaviour to be identical to ext234's.
Michal Schmidt [Wed, 22 Jul 2015 15:50:44 +0000 (17:50 +0200)]
basic: more optimizable IN_SET macro
Making the array static allows gcc -O2 to generate smaller code:
"size systemd" before:
text data bss dec hex filename 1377286 128608 2632 1508526 1704ae systemd
After:
text data bss dec hex filename 1374326 128572 2664 1505562 16f91a systemd
(IN_SET still results in worse generated code than using
"x == FOO || x == BAR || ...". I don't think we'll be able to match
that with the C preprocessor.)
This change limits the use of IN_SET to sets with constant elements. All
present callers use constants. The compiler would report an "initializer
element is not constant" error otherwise.
Michal Schmidt [Wed, 22 Jul 2015 15:05:41 +0000 (17:05 +0200)]
basic: better readable IN_SET macro
Putting the set elements in an array variable and using ELEMENTSOF makes
it clearer what's going on.
Incidentally, it also makes gcc -O2 generate slightly smaller code:
"size systemd", before:
text data bss dec hex filename 1378318 128608 2632 1509558 1708b6 systemd
After:
text data bss dec hex filename 1377286 128608 2632 1508526 1704ae systemd
Michal Schmidt [Tue, 21 Jul 2015 17:07:24 +0000 (19:07 +0200)]
core: adjust job completion message log levels
We do not print all non-OK job completion status messages to the console
in red, because not all of them are plain errors. We do however log the
same messages as LOG_ERR.
Differentiate the log levels by deducing them from the job result in a
way that more or less matches the color of the console message.
Michal Schmidt [Tue, 21 Jul 2015 12:54:24 +0000 (14:54 +0200)]
core: try harder to get job completion messages too
This is similar to "core: always try harder to get unit status
message format string", but for job completion status messages.
It makes generic status messages applicable for printing to the console.
And it rewrites the functions in a more table-based style.
Michal Schmidt [Mon, 20 Jul 2015 16:36:12 +0000 (18:36 +0200)]
core: unit_get_status_message_format() never returns NULL
unit_get_status_message_format() is used only with one of JOB_START,
JOB_STOP, JOB_RELOAD, all of which have fallback message strings
defined, so the function may never return NULL.
Daniel Mack [Mon, 20 Jul 2015 21:17:37 +0000 (23:17 +0200)]
user-sessions: fix write_string_file() fallout
WRITE_STRING_FILE_ATOMIC is only valid if WRITE_STRING_FILE_CREATE is also
given. IOW, an atomic file write operation is only possible when creating a
file is also being asked for.
This is a regression from the recent write_string_file() rework.
Daniel Mack [Mon, 20 Jul 2015 21:17:37 +0000 (23:17 +0200)]
logind: fix write_string_file() fallout
WRITE_STRING_FILE_ATOMIC is only valid if WRITE_STRING_FILE_CREATE is also
given. IOW, an atomic file write operation is only possible when creating a
file is also being asked for.
This is a regression from the recent write_string_file() rework.
Michal Schmidt [Mon, 20 Jul 2015 15:18:13 +0000 (17:18 +0200)]
core: always try harder to get unit status message format string
The starting/stopping messages are printed to the console only if the
corresponding format string is defined in the unit's vtable. To avoid
excessive messages on the console, the unit types whose start/stop
jobs are instantaneous had the format strings intentionally undefined.
When logging the same event to the journal, a fallback to generic
Starting/Stopping/Reloading messages is used.
The problem of excessive console messages with instantaneous jobs
is already resolved in a nicer way ("core: fix confusing logging of
instantaneous jobs"), so there's no longer a need to have two ways of
getting the format strings. Let's fold them into one function with
the fallback to generic message strings.
Michal Schmidt [Thu, 16 Jul 2015 19:39:56 +0000 (21:39 +0200)]
core: correct return value from reload methods
Return 1 from *_reload() methods to signify "we did something", just
like in *_start(). This causes "Reloading foo..." messages to be logged.
"Reloaded foo." messages are already logged.
Michal Schmidt [Thu, 16 Jul 2015 18:08:30 +0000 (20:08 +0200)]
core: fix confusing logging of instantaneous jobs
For instantaneous jobs (e.g. starting of targets, sockets, slices, or
Type=simple services) the log shows the job completion
before starting:
systemd[1]: Created slice -.slice.
systemd[1]: Starting -.slice.
systemd[1]: Created slice System Slice.
systemd[1]: Starting System Slice.
systemd[1]: Listening on Journal Audit Socket.
systemd[1]: Starting Journal Audit Socket.
systemd[1]: Reached target Timers.
systemd[1]: Starting Timers.
...
The reason is that the job completes before the ->start() method returns
and only then does unit_start() print the "Starting ..." message.
The same thing happens when stopping units.
Rather than fixing the order of the messages, let's just not emit the
Starting/Stopping message at all when the job completes instantaneously.
The job completion message is sufficient in this case.