Bug#1051392: closed by Debian FTP Masters (reply to Guillem Jover ) (Bug#1051392: fixed in victoriametrics 1.79.14+ds1-1)
Hi Guillem, thanks for taking care of this. The old version is still in stable as of today and is IMHO rendering victoria-metrics almost unusable (keeps crashing randomly, up to 10-15 times a day on my systems). Is there anything that could be done to push the fixed package to bookworm, at the very least for armhf ? Thanks again for your time and help, -Simon On 09/09/2023 00:24, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the victoria-metrics package: #1051392: Crash on unaligned reads on 32-bit arm architectures It has been closed by Debian FTP Masters (reply to Guillem Jover ). Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Debian FTP Masters (reply to Guillem Jover ) by replying to this email. -- Simon Vetter
Bug#1051392: Crash on unaligned reads on 32-bit arm architectures
Package: victoria-metrics
Version: 1.79.5+ds1-2+b5
Severity: grave
victoria-metrics v1.79.5 randomly crashes on aligned reads file reads,
rendering it more or less unusable.
Sep 7 08:46:31 localhost victoria-metrics[17179]: unexpected fault address 0x0
Sep 7 08:46:31 localhost kernel: [233869.646841] Alignment trap: not handling
instruction ed9c0b00 at [<005af9bc>]
Sep 7 08:46:31 localhost kernel: [233869.646882] 8<--- cut here ---
Sep 7 08:46:31 localhost kernel: [233869.646887] Unhandled fault: alignment
exception (0x001) at 0x02153612
Sep 7 08:46:31 localhost kernel: [233869.646898] [02153612] *pgd=3ea5d831
Sep 7 08:46:31 localhost victoria-metrics[17179]: fatal error: fault
Sep 7 08:46:31 localhost victoria-metrics[17179]: [signal SIGBUS: bus error
code=0x1 addr=0x0 pc=0x5af9c0]
Sep 7 08:46:31 localhost victoria-metrics[17179]: goroutine 28 [running]:
Sep 7 08:46:31 localhost victoria-metrics[17179]: runtime.throw({0x6abcef,
0x5})
Sep 7 08:46:31 localhost victoria-metrics[17179]: #011runtime/panic.go:1047
+0x4c fp=0x24993b4 sp=0x24993a0 pc=0x50424
Sep 7 08:46:31 localhost victoria-metrics[17179]: runtime.sigpanic()
Sep 7 08:46:31 localhost victoria-metrics[17179]:
#011runtime/signal_unix.go:832 +0xac fp=0x24993cc sp=0x24993b4 pc=0x69fc8
Sep 7 08:46:31 localhost victoria-metrics[17179]: math.IsNaN(...)
Sep 7 08:46:31 localhost victoria-metrics[17179]: #011math/bits.go:39
Sep 7 08:46:31 localhost victoria-metrics[17179]:
github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/promql.removeEmptySeries(...)
Sep 7 08:46:31 localhost victoria-metrics[17179]:
#011github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/promql/exec.go:157
Sep 7 08:46:31 localhost victoria-metrics[17179]:
github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/promql.timeseriesToResult({0x21fe3b0,
0x1, 0x2}, 0x1)
Sep 7 08:46:31 localhost victoria-metrics[17179]:
#011github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/promql/exec.go:99
+0x610 fp=0x24994ac sp=0x24993d0 pc=0x5af9c0
Sep 7 08:46:31 localhost victoria-metrics[17179]:
github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/promql.Exec(0x0,
0x28c6540, {0x201f325, 0x1a}, 0x0)
Sep 7 08:46:31 localhost victoria-metrics[17179]:
#011github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/promql/exec.go:58
+0x2ec fp=0x2499584 sp=0x24994ac pc=0x5aebbc
Sep 7 08:46:31 localhost victoria-metrics[17179]:
github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/prometheus.queryRangeHandler(0x0,
{0xc1368159f7200fc8, 0x299f41302, 0xb5cc08}, {0x81ffbc, 0x292a320},
{0x201f325, 0x1a}, 0x18a6b9c9ae0, 0x18a6bb93718, ...)
Sep 7 08:46:31 localhost victoria-metrics[17179]:
#011github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/prometheus/prometheus.go:840
+0x5f4 fp=0x2499748 sp=0x2499584 pc=0x5ea4cc
[...]
Seehttps://github.com/VictoriaMetrics/VictoriaMetrics/pull/3927 for more
details on the issue.
The bug has already been patched upstream and an LTS release (v1.79.11) has
been made in March, along with other important
fixes:https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v1.79.11
.
This is on an armhf box (hardkernel odroid-c1) running Debian 12.1, kernel
6.1.0-11-armmp, fully up to date.
Steps to reproduce:
- run victoria-metrics on a 32-bit arm system,
- ingest a small amount of data (my data directory is less than 10MB),
- query the data with e.g. grafana, by zooming in and moving the observed time
window.
Querying with some automated script should also work as all that needs to be
done is to cause an unaligned read on disk, which is a naturally occurring
condition due to how datapoints are stored and compressed.
Would it be possible to upgrade to that LTS release?
Thanks in advance,
-Simon
--
Simon Vetter
Bug#1007799: missing thermal driver for sun8i platforms running Bullseye 11.2
Package: linux-image-armmp-lpae Version: 5.10.103-1 On a freshly installed NanoPi NEO (sunxi 8) system running Bullseye 11.2 (all updates applied), the kernel is lacking the sun8i_thermal driver, preventing CPU temperature readings as well as thermal throttling operation. Depending on system load and thermal environment (ambient temperature, enclosure, heatsink, etc.), this may lead to overheating and/or damage to the hardware. # grep SUN8I_THERMAL /boot/config-5.10.0-12-armmp-lpae # CONFIG_SUN8I_THERMAL is not set Recompiling the kernel with that config option set to 'm' solved the issue (i.e. CONFIG_SUN8I_THERMAL=m), and I've been able to confirm that thermal throttling is indeed operational. Would you be able to change that config option and push an updated package? I figured I'd send a bug report sincehttps://wiki.debian.org/InstallingDebianOn/Allwinner lists the NanoPi NEO as stable/untested and welcomes reports. I believe other sun8i-based systems should be affected as well, but the NanoPi NEO is the only one I have around to play with. Cheers, -Simon -- Simon Vetter - CEO Vetter Technolgies
Bug#919525: race condition between sshguard and ufw on startup
Package: sshguard Version: 1.7.1-1 On systems with ufw (uncomplicated firewall, a popular firewall manager/frontend) *and* sshguard installed, a race condition exists between sshguard's firewall setup script and ufw. As I understand it, ufw calls iptables-restore on multiple files on startup to create and populate its various chains. If, during one of those calls, /usr/lib/sshguard/firewall is called to add the sshguard chain, the iptable-restore call fails and ufw cracks open. This has bitten me a few times, leaving remote boxes unreachable over the network after a reboot since ufw was unable to restore all of its rules. sshguard's systemd service file seems to have an After= directive which should prevent this, as ufw specifies a Before=network.target directive. [Unit] Description=SSHGuard Documentation=man:sshguard(8) After=network.service Before=sshd.service Since none of my Debian systems have a network.service file, I tried changing "After=network.service" to "After=network.target", which did the trick: sshguard is now started well after ufw, and after tens of reboots I haven't seen the issue come up again. Given my limited systemd knowledge, this may or may not be the best fix, but I believe something along these lines should be changed and a new package published. This is on Debian 9.6 (latest at the time of this writing), all packages up to date. Cheers, -Simon -- -- Simon Vetter Embedded Software Engineer - EDF store & forecast Phone: +33 7 83 40 26 11
Bug#900066: gitlab: 500 error on merge request creation
Thanks. I applied the update earlier this morning and can confirm that the bug is fixed. Cheers, -Simon -- Simon Vetter Embedded Software Engineer - EDF store & forecast Phone: +33 7 83 40 26 11 On 05/26/2018 03:36 PM, Salvatore Bonaccorso wrote: Hi, On Sat, May 26, 2018 at 06:25:40PM +0530, Pirate Praveen wrote: On Saturday 26 May 2018 03:34 PM, Simon Vetter wrote: Awesome, thank you for your prompt reply. In the meantime and assuming the fix is in non-compiled code (i.e. ruby), would you mind sharing a patch here so I can apply it and get merge requests up and running again? Sure, here is the patch. https://salsa.debian.org/ruby-team/gitlab/commit/cfdebd5834791b9152dc32af10a63b8db6ddbab9 The regression update (DSA-4206-2) has been issued and the packages available on the security mirrors. Regards, Salvatore
Bug#900066: gitlab: 500 error on merge request creation
Awesome, thank you for your prompt reply.
In the meantime and assuming the fix is in non-compiled code (i.e.
ruby), would you mind sharing a patch here so I can apply it and get
merge requests up and running again?
--
Simon Vetter
Embedded Software Engineer - EDF store & forecast
Phone: +33 7 83 40 26 11
On 05/26/2018 11:28 AM, Pirate Praveen wrote:
Control: tags -1 pending
On Friday 25 May 2018 09:03 PM, Simon Vetter wrote:
Processing by ProjectsController#autocomplete_sources as JSON
Parameters: {"type"=>"MergeRequest", "namespace_id"=>"operations",
"id"=>"ems"}
Completed 200 OK in 502ms (Views: 169.8ms | ActiveRecord: 53.2ms)
Started POST "/operations/ems/merge_requests" for [redacted ip
address] at 2018-05-25 16:09:41 +0100
Processing by Projects::MergeRequestsController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[redacted
token]", "merge_request"=>{"title"=>"[redacted merge request title]",
"description"=>"", "label_ids"=>[""],
"force_remove_source_branch"=>"0", "lock_version"=>"0",
"source_project_id"=>"1", "source_branch"=>"[redacted source git
branch]", "target_project_id"=>"1", "target_branch"=>"master"},
"namespace_id"=>"operations", "project_id"=>"ems"}
Completed 500 Internal Server Error in 123ms (ActiveRecord: 13.2ms)
NameError (undefined local variable or method `source_project' for
#
Did you mean? @source_project):
app/services/merge_requests/create_service.rb:6:in `execute'
app/controllers/projects/merge_requests_controller.rb:254:in `create'
lib/gitlab/request_profiler/middleware.rb:15:in `call'
lib/gitlab/middleware/go.rb:16:in `call'
Thanks for the report.
This is now fixed in the stretch-updates branch and waiting for
approval from security team to upload the fixed version.
Bug#900066: gitlab: 500 error on merge request creation
Package: gitlab
Version: 8.13.11+dfsg1-8+deb9u2
Severity: normal
* What led up to the situation?
I upgraded to the latest security update (8.13.11+dfsg1-8+deb9u2) and
rebooted the box.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I tried creating a new merge request.
* What was the outcome of this action?
Gitlab throws a 500 error "Whoops, something went wrong on our end." The
merge request is indeed not created (it does not show up in the merge
request list, which has other, previously created entries)
/var/log/gitlab/production.log shows the following error:
Processing by ProjectsController#autocomplete_sources as JSON
Parameters: {"type"=>"MergeRequest", "namespace_id"=>"operations",
"id"=>"ems"}
Completed 200 OK in 502ms (Views: 169.8ms | ActiveRecord: 53.2ms)
Started POST "/operations/ems/merge_requests" for [redacted ip address]
at 2018-05-25 16:09:41 +0100
Processing by Projects::MergeRequestsController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[redacted token]",
"merge_request"=>{"title"=>"[redacted merge request title]",
"description"=>"", "label_ids"=>[""], "force_remove_source_branch"=>"0",
"lock_version"=>"0", "source_project_id"=>"1",
"source_branch"=>"[redacted source git branch]",
"target_project_id"=>"1", "target_branch"=>"master"},
"namespace_id"=>"operations", "project_id"=>"ems"}
Completed 500 Internal Server Error in 123ms (ActiveRecord: 13.2ms)
NameError (undefined local variable or method `source_project' for
#
Did you mean? @source_project):
app/services/merge_requests/create_service.rb:6:in `execute'
app/controllers/projects/merge_requests_controller.rb:254:in `create'
lib/gitlab/request_profiler/middleware.rb:15:in `call'
lib/gitlab/middleware/go.rb:16:in `call'
* What outcome did you expect instead?
A merge request should have been created just fine. I should have been
taken to the created merge request page instead of being shown an error
page.
Earlier this morning before the upgrade, merge requests could be created
just fine. The system is fully up to date.
I tried re-installing gitlab with apt-get install --reinstall gitlab.
Rake tasks (which I assume were ran by the post-install script)
pre-compiled a bunch of assets once again and validated my config and
projects, but merge requests still can't be created.
Browsing projects/issues/other pages seem to work fine, although I
haven't checked every possible action.
-- System Information:
Debian Release: 9.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gitlab depends on:
ii adduser 3.115
ii asciidoctor 1.5.4-2
ii bc 1.06.95-9+b3
ii bundler 1.13.6-2
ii dbconfig-pgsql 2.0.8
ii debconf [debconf-2.0] 1.5.61
ii git 1:2.11.0-3+deb9u2
ii gitlab-shell 3.6.6-4
ii gitlab-workhorse 0.8.5+debian-3+b2
ii init-system-helpers 1.48
ii libjs-chartjs 1.0.2-1
ii libjs-clipboard 1.4.2-1
ii libjs-fuzzaldrin-plus 0.3.1+git.20161008.da2cb58+dfsg-4
ii libjs-graphael 0.5+dfsg-1
ii libjs-jquery-cookie 11-3
ii libjs-jquery-history 11-3
ii libjs-jquery-nicescroll 3.6.6-1
ii lsb-base 9.20161125
ii nginx 1.10.3-1+deb9u1
ii nginx-full [nginx] 1.10.3-1+deb9u1
ii nodejs 4.8.2~dfsg-1
ii openssh-client 1:7.4p1-10+deb9u3
ii postfix [mail-transport-agent] 3.1.8-0+deb9u1
ii postgresql-client 9.6+181+deb9u1
ii postgresql-client-9.6 [postgresql-client 9.6.7-0+deb9u1
ii postgresql-contrib 9.6+181+deb9u1
ii rake 10.5.0-2
ii redis-server 3:3.2.6-1
ii ruby 1:2.3.3
ii ruby-ace-rails-ap 4.1.1-1
ii ruby-activerecord-session-store 1.0.0-2
ii ruby-acts-as-taggable-on 4.0.0-2
ii ruby-addressable 2.4.0-1
ii ruby-after-commit-queue 1.3.0-1
ii ruby-akismet 2.0.0-1
ii ruby-allocations 1.0.3-1+b2
ii ruby-asana
Bug#425269: Status of ipv6 in psi
Hi, is there still a reason for holding ipv6 out of psi? It has been ported to QT4, so the DNS issue should have been fixed, thought i'm not sure of that. Could you try enabling it? ipv6 file transfer would be cool, too, but upstream doesn't support it yet. Regards, Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
