Date: Thu, 15 Jan 2026 04:06:53 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 292472] sysutils/alloy: problems stopping Message-ID: <bug-292472-7788@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292472 Bug ID: 292472 Summary: sysutils/alloy: problems stopping Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: ports-bugs@FreeBSD.org Reporter: bob@vesterman.com CC: zach.leslie@grafana.com CC: zach.leslie@grafana.com Flags: maintainer-feedback?(zach.leslie@grafana.com) Created attachment 267155 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=267155&action=edit alloy's log messages starting from when it received the stop command I've recently started using Grafana, Alloy, and Loki. It's all working mostly OK, but I've noticed that Alloy sometimes just never stops when I do a "service alloy stop". To be clear, by "never stops", I mean "never stops running"; it absolutely does stop processing input. In these cases, it closes a bunch of stuff -- files it's scanning and a network port it's listening to for syslog messages -- and... that's it; nothing further seems to be done. Typically I'm trying to stop it via a cron job, in order to get it to reload its SSH certificate (which is frequently updated), though I have sometimes noticed this issue when trying to stop it manually, too. At first, the cron job script was very simple, since I'm an extremely lazy man: -------------------------- #!/bin/sh service alloy restart -------------------------- It often worked. It sometimes didn't. While investigating, I noticed that when it's in this state, I was able to stop it simply by issuing another "service alloy stop". So, I changed the script to check if the process has stopped; if it did, it then starts it, but if not it sleeps a little and then tries stopping it again, over and over: -------------------------- #!/usr/local/bin/bash stopped=false until "$stopped" do service alloy stop service alloy status if ! service alloy status then stopped=true else sleep 3 fi done service alloy start -------------------------- Again, it sometimes worked. But today, it didn't. Investigating, it seems that it's not (as I intended) periodically trying to stop the process; instead, the "stop" itself seems to be hanging: -------------------------- # ps aux -ww | rg alloy root 89205 0.0 0.0 15664 3732 - I 15:41 0:00.00 /usr/local/bin/bash ./reload-alloy root 89373 0.0 0.0 14744 3140 - I 15:41 0:00.03 /bin/sh /usr/local/etc/rc.d/alloy stop -------------------------- I've redacted various lines from that output to leave only the two that I think are important here: (1) my script; (2) the actual stop attempt. Note that both of these have been running since 15:41, which was several hours ago. This is why I said that the "stop" itself seems to be hanging (as opposed to the script periodically trying to stop alloy over and over). Also of possible note is that another ps shows that the "/bin/sh /usr/local/etc/rc.d/alloy stop" is the parent of a "pwait -op 88127" -- which has also been going since 15:41 -- and a third ps shows that 88127 is the actual running alloy process. As I mentioned earlier, alloy has closed things. A sockstat command would normally show that it is listening on a network port (for syslog messages), and perhaps other things too which I don't recall at the moment, but: -------------------------- # sockstat | rg alloy alloy daemon 87648 3 dgram ?? -> /var/run/log -------------------------- And while I don't actually know what "lsof" shows under normal conditions (have never checked), it certainly seems like it should show that alloy has a bunch of files from /var/log open (I have it set up to scan a bunch of them with "loki.source.file"). But it doesn't: -------------------------- # lsof | rg "^alloy" | awk '{print $9}' | sort | uniq -c 3 2 / 1 /usr/local/bin/alloy 18 /usr/local/bobconfig/stowfiles/alloy/usr/local/etc/alloy/SENSITIVE/password.loki 1 /usr/local/bobconfig/stowfiles/alloy/usr/local/etc/alloy/imports 1 /usr/local/bobconfig/stowfiles/alloy/usr/local/etc/alloy/imports/caddy.alloy 1 /usr/local/bobconfig/stowfiles/alloy/usr/local/etc/alloy/imports/caddy_access.alloy 18 /usr/local/bobconfig/stowfiles/alloy/usr/local/etc/alloy/imports/loki.alloy 1 /usr/local/bobconfig/stowfiles/alloy/usr/local/etc/alloy/imports/syslog-ng.alloy 1 state=0x2 -------------------------- I don't know enough about low-level stuff to understand what the blanks, the ""state=0x2", and the root directory are open for, but the remainder of those are just the executable itself and a bunch of config files/directories. Finally, I am attaching a file that shows all of the log messages that alloy put out from the time that it received the stop (i.e. 15:41) forward. If there is any other information I may be able to provide which might help, please let me know. Thanks in advance for any help. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-292472-7788>