Vladimír Čunát authored 5 years ago and Petr Špaček committed 5 years ago

Trying to avoid https://github.com/google/sanitizers/issues/1010

daemon/main: support multiple config files

See merge request !909

Tomas Krizek authored 5 years ago and Petr Špaček committed 5 years ago

The exact same function is implemented as luaL_dofile() in Lua 5.1,
there seems to be no reason to use our project-specific macro for it.

https://www.lua.org/manual/5.1/manual.html#luaL_dofile

prefill: remove depedency on lua-filesystem (lfs)

Closes #520

See merge request !912

ci: allow failure of obs:build:all

See merge request !910

This job tends to fail very often, but very frequently due to issues
with OBS itself - outside of our control. The output of the job can
still be useful to check manually, e.g. before releases.

This value seems to be the default, but it is important to have
it set explicitly, otherwise when: manual actions could be skipped

https://docs.gitlab.com/ee/ci/yaml/#whenmanual

lua: stop trying to tweak lua's GC

See merge request !201

Tomas Krizek authored 5 years ago and Petr Špaček committed 5 years ago

cherry-picked from f0ca89ac, original author Vlada Cunat

TL;DR: I believe all lua_gc() calls stemmed from misunderstanding lua
documentation, and the current settings seem potentially dangerous.

First, let me rely on lua 5.1 docs, as luajit 2 is documented to have
done only minor changes in the GC.
http://www.lua.org/manual/5.1/manual.html#lua_gc
http://wiki.luajit.org/New-Garbage-Collector#rationale

Commit 5a709411 claims to have increased the speed of GC to 400 % of
speed of allocation, but LUA_GCSETSTEPMUL is the parameter that
controls that, and that one was lowered to 99 % and later in
0ee2d1d7 even to 50 %.  Documentation explicitly says that setting
the value under 100 % may cause problems.

The default values seem perfectly sane to me and currently I can't see
any particular reason to change them.  It's 200 % relative GC speed,
and waiting for allocated size to double before starting another cycle.

I assume the resulting possibility of GC being too slow caused the need
to explicitly force a non-incremental GC cycle once in a while, but
that seems not useful anymore and not good for latency.

daemon/io: use SO_REUSEPORT_LB if available (FreeBSD 12.0+)

See merge request !907

Vladimír Čunát authored 5 years ago and Petr Špaček committed 5 years ago

and don't use SO_REUSEPORT on non-Linux.  (Free)BSD has a different
meaning for it, which only brings confusion - only the last instance
would be getting packets.

daemon/ tty commands: don't log unless --verbose

Closes #528

See merge request !908

It's minimalistic: no change if in interactive or --verbose mode.

systemd: add env variable SYSTEMD_INSTANCE

See merge request !906

ci: updates

See merge request !905

update NEWS, bump to 4.3.0

See merge request !904