Previously, get_display_timestamp() is unconditionally called even if we
will show logs in e.g. json format.
This drops unnecessary call of get_display_timestamp().
This also makes journal fields in each entry parsed only once in
output_short(). Still output_verbose() twice though.
This should improve performance of dumping journals.
Replaces #29365.
Co-authored-by: Costa Tsaousis <costa@netdata.cloud>
Note, even with this, memory allocated internally by glibc is not freed.
But, at least, memory explicitly allocated by us is freed cleanly even
Ctrl-C is pressed during 'journalctl --follow'.
Closes#30995.
When the offset of the last entry object (or last object for journal
files generated by an old journald) is not changed, the timestamps
should be updated by journal_file_read_tail_timestamp() are unchanged.
So, we can drop to call fstat() in the function.
As, the journal header is always mapped, so we can read the offset and
journal file state without calling fstat.
Still, when the last entry offset is changed, we may need to call fstat()
to read the entry object. But, hopefully the number of fstat() call
can be reduced.
In journal_file_next_entry(), if the passed offset matches an entry object,
then generic_array_bisect() returns the object, but the object we
requested is the next (or previous) object. Hence, we should not validate
the object returned by generic_array_bisect(), otherwise it may fail
when the journal is corrupted.
Note the validity of the entry object that should be returned by
journal_file_next_entry() will be checked in the following generic_array_get().
So, when journal_file_next_entry() succeeds, the returned object is
always validated.
Let's consider the case that
- the first array contains valid entries,
- all entries in the second array are corrupted.
Then, when we are going to upwards, and a call of generic_array_bisect()
matches the last entry of the first array, then the second array was
cached with last_index == UINT64_MAX, instead of the first array with
its last entry.
Hence, when generic_array_bisect() is called next time, the function call
of test() always fail. So, the cache entry is mostly meaningless.
Let's always store valid cache entry.
Prompted by https://github.com/systemd/systemd/pull/30085#discussion_r1401534107.
Note, like Reconfigure bus method, even reconfiguration for an interface is
triggered by Reload method, the method only wait for the link enters
configuring state (or unmanaged state if no matching .network file exists).
Users still need to invoke systemd-networkd-wait-online if it is
necessary to wait for the interface enters configured state after Reload
medhod.
Previously, if address_remove() or friends called with a temporary
object, the removing flag is assigned to the temporary object, and is
not set to the remembered object. Hence, e.g.
route_is_ready_to_configure() wrongly judge a required address for a
route is (still) ready, hence networkd fails to configure the route.
Fixes#28009.
Follow-up for 0a0c2672db.
After the commit, remembered Address objects by Link are always given by
kernel. Hence, it is not necessary to set the flag, as it is always
ignored by the kernel, and the kernel set the flag on notification if it
is necessary.
Fixes an issue caused by ab3aed4a03 (v253).
By default, all managed interface need to be configured, and at least
one interface need to be online. Hence, offline interface should be ignored.
Fixes#29506.
In pam_systemd.so and pam_systemd_home.so, we open a bus connection on
session close, which is called after fork. Closing the connection is
harmless, and should not warn about that.
This suppresses the following log message:
===
(sd-pam)[127]: PAM Attempted to close sd-bus after fork, this should not happen.
===
The man page pam_setcred(3) states:
> The credentials should be deleted after the session has been closed
> (with pam_close_session(3)).
Follow-up for 3bb39ea936.
This makes rtnl_resolve_interface() always check the existence of the
resolved interface, which previously did not when a decimal formatted
ifindex is provided, e.g. "1" or "42".
If a nexthop is removed, dependent routes are silently removed by the kernel.
Hence, networkd may be confused that routes that depends on the nexthop still
exist, and may fail to configure other routes or so.
This is the one for routes of 3cbbe8635a.
If we could not remove a route, then previously the corresponding
Route object was never removed, as it was freed only when we receive
remove notification from the kernel. So, we might confused that the
route still exists and being removed, and might block reconfiguring
the route.
With this change, even if we fail to remove a route, the corresponding
Route object will be freed.
This is the one for routes of 56a995fe8e.
Then, replace route_remove_and_drop() with it.
If a route is requested, and the request is already called,
we may not received its reply and notification from the kernel, and
the corresponding Route object may not be remembered. Even in such
case, we need to remove the route, otherwise the route will come
later after the function called.
This is the version for route of f22b586a21.
Previously, a Route object is owned by a Link object corresponding to the
outgoing interface of the route, and a Route object that does not have
outgoing interface is owned by the Manager object.
However, there were several issues:
- if a route has a nexthop ID, then the corresponding nexthop may be
changed to use another interface, hence the outgoing interface of the
route may be changed.
- if a route requested with MultiPathRoute=, then the link who requests
the route is different from the outgoing interface of the configured
route. So, we need to find routes on other interfaces on reconfiguring
or so.
By this change, the limit of the number of routes per-interface is
tentatively dropped. Let's re-introduce the limit later in a nicer way.
Yu Watanabe
