From nobody Mon Feb 9 04:19:44 2026 X-Original-To: ports-bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f8WgN62Rnz6SDRd for ; Mon, 09 Feb 2026 04:19:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f8WgN5WhXz3vhv for ; Mon, 09 Feb 2026 04:19:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770610784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=clvpgekLq5+2ZcSGydZHaLWiW3FDniJ3Ncaw3gsoDDs=; b=NnKXoWLG7SdasXGJRjfgCMkPgPhaJLH3Rw30/iD6nrsS+gTPYxhR49Yr3Cn1iE5QtVwUEX G62LNtXfbDajusIwlyAl9ByCl9jZhyfLWY3+01EaOHHU7e7b2+nK/daCHpIkH6qLictkxD XjSZ+pYhsgm1Dyb0RglN755UjPNBO0MHSZSuU145Mj7P7ueapj9Pf6uIzkBQPgpcdICkYp L5FCczGQv3ERkiF14zbrrCIkAh31+/lGIWRCjnqgIWd1c4MGEeYkbYDgovVZoNdIX/5pqz OuITumO5Ezg5wTwqCD5p7osl3RFWZUk2rdbxHSKS4zEAGKkmI8ddLB27BbgkLQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770610784; a=rsa-sha256; cv=none; b=rOJkHAI+UAs4trN9khYf7Akf+g0VZyDbIRxkbiWl4O84amIbD69q+61ZFFI3vAHwS8+sbP phwIRpz638lc4EMysu9TjUnOrJLJrhBlfCJ5s243tRoTLnL226khlaf+ba4WJtskWzbDvU z6MdK79LfvlKBiQlOl0eCzMQ9AxwEmb51iLfnaSICQ+wtHrBaVSlIXmWxJAwhmSqUW3mP8 fGK1yunqz267tl0FVjy/CbiAjQZZKm4lIGr3Kz1bw1rLRHwX3/1CaEvQ2edylHMGVISbz2 NauMSSa09mgbVAMnATg0NN34L/OS1d5S1FGSygooZonpAI513o1zMuwsGyT2BQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770610784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=clvpgekLq5+2ZcSGydZHaLWiW3FDniJ3Ncaw3gsoDDs=; b=FiWTH4UjgQ9WQlSBMda3yG+HHWLtWpx49IHUjMhxpcbx3P0O8Sg5JxSnYvq0Lsum3Lhfri JqihooNawS8ZgT2sPfhU1rV19mrnVbi9kXaE855lkRApTCGS8Ka9LNOz/ZHR4+H1HQ2ET5 eXDciaWCRhaiOa6741ePtpTzkDw6Wd2SBoh9GgXdaTidwXfSaHI9uqSZYGFpku+br4V3PB geMrI6G0t4GIYlO0NaRLW6yXBwZdIwByiVuwNfl2mwSPc24vsBNEWXknCmeKiwsHJoIs9k tOEwkngiLqtZVfN1kUZRmgOykX9QQkw/5fMZ8dX4e2MFQmwXXiNXj7rPdyR3NA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4f8WgN4wYYz2fC for ; Mon, 09 Feb 2026 04:19:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 6194Jiig086499 for ; Mon, 9 Feb 2026 04:19:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 6194JiUK086498 for ports-bugs@FreeBSD.org; Mon, 9 Feb 2026 04:19:44 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 292472] sysutils/alloy: problems stopping Date: Mon, 09 Feb 2026 04:19:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bob@vesterman.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-ports-bugs@freebsd.org Sender: owner-freebsd-ports-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D292472 --- Comment #4 from Robert William Vesterman --- Hi, first, thanks. Second, I apologize for not replying sooner. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "Can you say more about the SSH key that gets updated? I wonder if the fil= e is being replaced but the old handle is held open, if that could cause a failu= re to shutdown." Well, for a couple reasons, I don't think that's the culprit: (1) If I understand the output of lsof correctly, it seems to show that All= oy does not keep that file open during regular operation, nor does it have that file open when the process is in this weird shutdown state. (2) The problem occurs (not every time, but once in a while) regardless of whether the post-SSL-renewal cron job was the thing that initiated the stop= or not; i.e. it sometimes occurs even if I just try manually stopping it. With that said, here's how the cert file is updated: A cron job runs a script a couple times an hour. That script checks if the certificate is (in some sense) close to expiration. If so, it asks for rene= wal via ACME challenge to a CA that's running on (and for) my local network. Af= ter successful renewal, it copies the new key and cert to the locations where A= lloy expects them. Originally (at the time I wrote the first message in this bug report), it w= ould then stop/start Alloy to try to get it to pick up the new cert. However, si= nce that time, I discovered that I don't actually need to stop/start Alloy, so = the script no longer does this. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "I also notice multiple loki.write.loki shutdown messages in the logs, whic= h I take to mean that you have multiple loki.write objects. Are these to the s= ame API endpoint?" Yes, Alloy writes everything to a single Loki endpoint. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "Around the imports, I'm not familiar, but is it possible you have circular imports?" I really don't think so. I mean, I might be screwing it up due to misunderstanding, but the intent (and, as far as I can tell, the reality) is that the only import file that any of my imported files themselves import ("loki.alloy") does not itself import any import files. That file is where = the loki endpoint is defined. Here is my alloy.flow and all of my import files (note that the first, alloy.flow, is modified for brevity - I'm showing only two of the fifteen "rwv37_caddy_access" blocks that it uses, but they're all basically the same sort of thing): ----------------- # cat alloy.flow import.file "imports" { filename =3D "/usr/local/etc/alloy/imports/" } imports.rwv37_loki "importLoki" {} imports.rwv37_syslog_ng "importSyslogNG" {} imports.rwv37_caddy "importCaddy" {} imports.rwv37_caddy_access "importCaddyAccessSvn" { access_file_name =3D "svn.vestertopia.net_https.log" scheme =3D "https" site =3D "svn.vestertopia.net" } imports.rwv37_caddy_access "importCaddyAccessCa" { access_file_name =3D "ca.vestertopia.net_https.log" scheme =3D "https" site =3D "ca.vestertopia.net" } ----------------- # cat caddy.alloy declare "rwv37_caddy" { import.file "imports" { filename =3D "/usr/local/etc/alloy/imports/loki.alloy" } imports.rwv37_loki "importLoki" { } argument "forward_to" { optional =3D true default =3D [ imports.rwv37_loki.importLoki.receiver ] } loki.source.file "caddy_main" { targets =3D [ {__path__ =3D "/var/log/caddy/caddy.log" } ] forward_to =3D [ loki.process.transform.receiver ] } loki.process "transform" { stage.labels { values =3D { job =3D "filename", } } stage.static_labels { values =3D { application =3D "caddy", } } forward_to =3D argument.forward_to.value } } ----------------- # cat caddy_access.alloy declare "rwv37_caddy_access" { import.file "imports" { filename =3D "/usr/local/etc/alloy/imports/loki.alloy" } imports.rwv37_loki "importLoki" { } argument "access_file_name" { optional =3D false } argument "forward_to" { optional =3D true default =3D [ imports.rwv37_loki.importLoki.receiver ] } argument "scheme" { optional =3D false } argument "site" { optional =3D false } loki.source.file "caddy_access" { targets =3D [ {__path__ =3D file.path_join("/var/log/caddy/access/", argument.access_file_name.value)}, ] forward_to =3D [ loki.process.transform.receiver ] } loki.process "transform" { stage.labels { values =3D { job =3D "filename", } } stage.static_labels { values =3D { application =3D "caddy", scheme =3D argument.scheme.value, site =3D argument.site.value, } } forward_to =3D argument.forward_to.value } } ----------------- # cat loki.alloy declare "rwv37_loki" { local.file "password_loki" { filename =3D "/usr/local/etc/alloy/SENSITIVE/password.loki" is_secret =3D true } loki.write "loki" { endpoint { url =3D "https://loki.vestertopia.net/loki/api/v1/push" basic_auth { username =3D "loki" password =3D local.file.password_loki.content } } } export "receiver" { value =3D loki.write.loki.receiver } } ----------------- # cat syslog-ng.alloy declare "rwv37_syslog_ng" { import.file "imports" { filename =3D "/usr/local/etc/alloy/imports/loki.alloy" } imports.rwv37_loki "importLoki" { } argument "forward_to" { optional =3D true default =3D [ imports.rwv37_loki.importLoki.receiver ] } discovery.relabel "syslog" { targets =3D [] rule { source_labels =3D ["__syslog_message_hostname"] target_label =3D "host" } rule { source_labels =3D ["__syslog_message_hostname"] target_label =3D "hostname" } rule { source_labels =3D ["__syslog_message_severity"]=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 23:06 [25/1855] target_label =3D "level" } rule { source_labels =3D ["__syslog_message_app_name"] target_label =3D "application" } rule { source_labels =3D ["__syslog_message_facility"] target_label =3D "facility" } rule { source_labels =3D ["__syslog_connection_hostname"] target_label =3D "connection_hostname" } } loki.source.syslog "syslog_tls" { listener { address =3D "10.0.26.1:6514" protocol =3D "tcp" idle_timeout =3D "37m" use_rfc5424_message =3D true labels =3D { job =3D "syslog", component =3D "loki.source.syslog= ", protocol =3D "tcp/tls" } max_message_length =3D 0 tls_config { ca_file =3D "/usr/local/etc/alloy/SENSITIVE/certs/np-az.crt" cert_file =3D "/usr/local/etc/alloy/SENSITIVE/certs/alloy.cr= t" key_file =3D "/usr/local/etc/alloy/SENSITIVE/certs/alloy.key" min_version =3D "TLS13" server_name =3D "logs.vestertopia.net" } } forward_to =3D [loki.process.syslog.receiver] relabel_rules =3D discovery.relabel.syslog.rules } loki.process "syslog" { stage.match { selector =3D "{application=3D\"devd\", level=3D\"debug\"}" action =3D "drop" drop_counter_reason =3D "devd debug" } forward_to =3D argument.forward_to.value } } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "If so, I wonder if you can take my config as an example to open multipole files but use only one loki.write example." Thanks, I'll take a look at your stuff when I get a chance. --=20 You are receiving this mail because: You are the assignee for the bug.=