5c2cdaf...
by
Lennart Poettering <email address hidden>
core: rework how we flush incoming traffic when a socket unit goes down
Previously, we'd simply close and reopen the socket file descriptors. This is
problematic however, as we won't transition through the SOCKET_CHOWN state
then, and thus the file ownership won't be correct for the sockets.
Rework the flushing logic, and actually read any queued data from the sockets
for flushing, and accept any queued messages and disconnect them.
5ed2a9f...
by
Lennart Poettering <email address hidden>
core: move start ratelimiting check after condition checks
With #2564 unit start rate limiting was moved from after the condition checks
are to before they are made, in an attempt to fix #2467. This however resulted
in #2684. However, with a previous commit a concept of per socket unit trigger
rate limiting has been added, to fix #2467 more comprehensively, hence the
start limit can be moved after the condition checks again, thus fixing #2684.
Fixes: #2684
6f366e3...
by
Lennart Poettering <email address hidden>
core: introduce activation rate limiting for socket units
This adds two new settings TriggerLimitIntervalSec= and TriggerLimitBurst= that
define a rate limit for activation of socket units. When the limit is hit, the
socket is is put into a failure mode. This is an alternative fix for #2467,
since the original fix resulted in issue #2684.
In a later commit the StartLimitInterval=/StartLimitBurst= rate limiter will be
changed to be applied after any start conditions checks are made. This way,
there are two separate rate limiters enforced: one at triggering time, before
any jobs are queued with this patch, as well as the start limit that is moved
again to be run immediately before the unit is activated. Condition checks are
done in between the two, and thus no longer affect the start limit.
ab08fa0...
by
=?utf-8?q?Jo=C3=A3o_Paulo_Rechi_Vita?= <email address hidden>
Merge pull request #39 from endlessm/T11645-lib64-symlink
In Debian's glibc package, ld-linux-x86-64.so.2 symlinks are created in /lib64
and /usr/lib/x86_64-linux-gnu. If /lib is a symlink to usr/lib and /lib64 is a
symlink to usr/lib/x86_64-linux-gnu, these links end up at the same path. In
that case, dpkg may remove them both on upgrade, making the system unusable
because there's no longer a /lib64/ld-linux-x86-64.so.2 linker available.
I'm not sure why you would ever want /lib64 -> usr/lib/x86_64-linux-gnu, but
it's definitely wrong on Endless. There should already be a /lib64 -> usr/lib64
symlink in place, but unfortunately eos-convert-system was missing support to
copy that from the deployment.
