** Changed in: procps (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1864423
Title:
Failed test 'default log is not used' with new procps 3.3.16-1
To manage no
This bug was fixed in the package postgresql-common - 213
---
postgresql-common (213) unstable; urgency=medium
[ Christian Ehrhardt ]
* t/020_create_sql_remove.t: fix file clear with procps 3.16. (LP: #1864423)
[ Christoph Berg ]
* pg_lsclusters: List clusters even if the cor
Tests are all good now, things should migrate once britney gets to them
...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1864423
Title:
Failed test 'default log is not used' with new procps 3.3.16-
FYI:
- postgresql-common itself had a flaky test on armhf (re-started) and should
migrate soon (everything else is good)
- I triggered the procps tests with the new postgresql-common
@Steve - thanks for picking up the cleanup of the fs.protected_regular
setting on procps itself
--
You received
The behavior change is because the new procps from Debian is setting an
additional sysctl setting: ./debian/protect-
links.conf:fs.protected_regular = 2
systemd in 20.04 was previously setting this to 1, which led to some
issues, discussed at https://lists.ubuntu.com/archives/ubuntu-
devel/2020-Fe
Submitted to Debian via:
https://salsa.debian.org/postgresql/postgresql-common/merge_requests/8
And if there are no other blockers Myon will do an upload soon, so we
can sync and retest procps against that then.
** Changed in: postgresql-common (Ubuntu)
Status: New => In Progress
--
You
I see no difference between the simple test above and the status when
the real test is running:
Bad:
-rw-r- 1 postgres adm 559 Feb 24 10:55
/var/log/postgresql/postgresql-12-main.log
12 main 5432 online postgres /var/lib/postgresql/12/main
/var/log/postgresql/postgresql-12-main.log
Good:
-r
I found that it depends on file permissions/ownership.
The construct:
open L, ">$default_log"; close L; # empty default log file
only works if you are the file owner.
The test is running as root and the open/close will fail to open the
postgres:adm opened file.
A simple test might look like:
us
The failing tests are part of 020_create_sql_remove.t:
The checks are like:
ok -z $default_log, "default log is not used";
And $default_log points to /var/log/postgresql/postgresql-12-main.log in
both cases.
Entering interactive mode on fail:
$ sudo ./testsuite -f 20 -V -s
Eventually the whol
Replacing the perl construct
open L, ">$default_log"; close L; # empty default log file
with the also more readable:
truncate "$default_log", 0;
Fixes the issue in postgresql-common.
That might be a fix for this particular test, but (unfortunately) the
construct above is a common use-case in per
A trivial check like:
$ echo foo > testfile; perl -e 'my $test = "/home/ubuntu/testfile"; open L,
">$test"; close L;' cat testfile
Is not broken, it must be more special to the test env of postgresql-
common ?!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
11 matches
Mail list logo
