Handle the case where the target does not exist
in the process of deleting unused clients.
Such a situation will not occur in newly launched containers,
but will occur if they are restarted.
During container restarts, container status are preserved.
If the unused database client was deleted in the last run,
grep will not match anything.
It returns non-zero code and the container stops there
because entrypoint sets option `-e`
(exit immediately on non-zero exit code excluding some special cases)
This commit make the uninstall process to handle the case
UNUSED_DB_CLIENTS is empty.
Unused clients are determinate by checking ~/.postgresqlrc
Uninstall logs like the following will appear in the docker log:
- Uninstalling unused version(s) of client: postgresql-client-12
It is intended to work even in environments without an internet connection.
- Use latest version of pg_isready on checking database connection
- Switch postgresql-client version checking server on startup
- If the server versions do not match exactly, use the latest installed client
and warn on docker log
From postgresql documentation:
https://www.postgresql.org/docs/15/app-pgdump.html#PG-DUMP-NOTES
> Also, it is not guaranteed that pg_dump's output can be loaded
> into a server of an older major version — not even if the dump
> was taken from a server of that version.
To switch client version, generate a file ~/.postgresqlrc with content like:
{server side major version} {server hostname}:{server port} {default database}
See detail on:
https://manpages.ubuntu.com/manpages/bionic/man5/postgresqlrc.5.html
Following messages appear on docker log:
- Detected server version: 140007
- Generating /home/git/.postgresqlrc
`assets/build/config/database.yml.postgresql` is owned by root:root,
and permission is rwxrw----
so the user `git` (`${GILTAB_USER}`) doesn't have a permission to copy the file.
This raises an error while building.
This allows to the client to explicitly select protocol version 2, which is much more efficient. Without allowing that environment variable it seems that SSH connections are always stuck in version1. See https://docs.gitlab.com/ee/administration/git_protocol.html on how to check if protocol 2 is used.
Sidekiq is updated to v6.0 here (first contained tag: v14.4.0-ee)
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69655
In Sidekiq 6.0, these options have been marked as "deprecated":
-P (set pid file)
-L (set log file)
See https://github.com/sidekiq/sidekiq/commit/3f5b1c5
Now, we can see error message in {GITLAB_LOGS_DIR}/supervisor/sidekiq.log
like below:
----
ERROR: PID file creation was removed in Sidekiq 6.0, please use a proper process supervisor to start and manage your services
ERROR: Logfile redirection was removed in Sidekiq 6.0, Sidekiq will only log to STDOUT
----
Just stop using this option.
There are many warnings like below
recorded in {GITLAB_LOG_DIR}/supervisord/sidekiq.log.
This can be avoided by simply increasing SIDEKIQ_MEMORY_KILLER_MAX_RSS.
----
{
"severity": "WARN",
"time": "[MASKED]",
"class": "Gitlab::SidekiqDaemon::MemoryKiller",
"pid": [MASKED],
"message": "Sidekiq worker RSS out of range",
"current_rss": 1009636,
"soft_limit_rss": 1000000,
"hard_limit_rss": [MASKED],
"memory_total_kb": [MASKED],
"reason": "current_rss(1009636) \u003e soft_limit_rss(1000000)",
"running_jobs": [],
"retry": 0
}
----
For sameersbn/gitlab, this parameter have been introduced with
following commit on May 21, 2015 and never updated until today:
e4008cc7ab9efd626511af4c43e52e2a9490d612
On upstream, the default setting documentation is updated here:
https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31682
but it is said "the documentation is outdated" at this time.
I could not find out when the value is increased.
At least, In omnibus-gitlab, this have been introduced in MR 2360
(release 11.10.0+ce.0 / 11.10.0+ee.0)
https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/2360
