Skip site navigation (1)Skip section navigation (2) 
Date:      Mon, 09 Feb 2026 04:19:44 +0000
From:      bugzilla-noreply@freebsd.org
To:        ports-bugs@FreeBSD.org
Subject:   [Bug 292472] sysutils/alloy: problems stopping
Message-ID:  <bug-292472-7788-LLplW6mimJ@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-292472-7788@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292472

--- Comment #4 from Robert William Vesterman <bob@vesterman.com> ---
Hi, first, thanks. Second, I apologize for not replying sooner.

========================

"Can you say more about the SSH key that gets updated?  I wonder if the file is
being replaced but the old handle is held open, if that could cause a failure
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 Alloy
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 renewal
via ACME challenge to a CA that's running on (and for) my local network. After
successful renewal, it copies the new key and cert to the locations where Alloy
expects them.

Originally (at the time I wrote the first message in this bug report), it would
then stop/start Alloy to try to get it to pick up the new cert. However, since
that time, I discovered that I don't actually need to stop/start Alloy, so the
script no longer does this.

========================

"I also notice multiple loki.write.loki shutdown messages in the logs, which I
take to mean that you have multiple loki.write objects.  Are these to the same
API endpoint?"

Yes, Alloy writes everything to a single Loki endpoint.

========================

"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 = "/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 = "svn.vestertopia.net_https.log"
   scheme = "https"
   site = "svn.vestertopia.net"
}

imports.rwv37_caddy_access "importCaddyAccessCa" {
   access_file_name = "ca.vestertopia.net_https.log"
   scheme = "https"
   site = "ca.vestertopia.net"
}
-----------------
# cat caddy.alloy

declare "rwv37_caddy" {
   import.file "imports" {
      filename = "/usr/local/etc/alloy/imports/loki.alloy"
   }

   imports.rwv37_loki "importLoki" {
   }

   argument "forward_to" {
      optional = true
      default = [ imports.rwv37_loki.importLoki.receiver ]
   }

   loki.source.file "caddy_main" {
      targets = [ {__path__ = "/var/log/caddy/caddy.log" } ]
      forward_to = [ loki.process.transform.receiver ]
   }

   loki.process "transform" {
      stage.labels {
         values = {
            job = "filename",
         }
      }

      stage.static_labels {
         values = {
            application = "caddy",
         }
      }
      forward_to = argument.forward_to.value
   }
}
-----------------
# cat caddy_access.alloy

declare "rwv37_caddy_access" {
   import.file "imports" {
      filename = "/usr/local/etc/alloy/imports/loki.alloy"
   }

   imports.rwv37_loki "importLoki" {
   }

   argument "access_file_name" {
      optional = false
   }

   argument "forward_to" {
      optional = true
      default = [ imports.rwv37_loki.importLoki.receiver ]
   }

   argument "scheme" {
      optional = false
   }

   argument "site" {
      optional = false
   }

   loki.source.file "caddy_access" {
      targets = [ {__path__ = file.path_join("/var/log/caddy/access/",
argument.access_file_name.value)}, ]
      forward_to = [ loki.process.transform.receiver ]
   }

   loki.process "transform" {
      stage.labels {
         values = {
            job = "filename",
         }
      }

      stage.static_labels {
         values = {
            application = "caddy",
            scheme = argument.scheme.value,
            site = argument.site.value,
         }
      }
      forward_to = argument.forward_to.value
   }
}
-----------------
# cat loki.alloy

declare "rwv37_loki" {
   local.file "password_loki" {
       filename = "/usr/local/etc/alloy/SENSITIVE/password.loki"
       is_secret = true
   }

   loki.write "loki" {
       endpoint {
           url = "https://loki.vestertopia.net/loki/api/v1/push"

           basic_auth {
               username = "loki"
               password = local.file.password_loki.content
           }
       }
   }

   export "receiver" {
      value = loki.write.loki.receiver
   }
}
-----------------
# cat syslog-ng.alloy

declare "rwv37_syslog_ng" {
   import.file "imports" {
      filename = "/usr/local/etc/alloy/imports/loki.alloy"
   }

   imports.rwv37_loki "importLoki" {
   }

   argument "forward_to" {
      optional = true
      default = [ imports.rwv37_loki.importLoki.receiver ]
   }

   discovery.relabel "syslog" {
       targets = []

       rule {
           source_labels = ["__syslog_message_hostname"]
           target_label  = "host"
       }

       rule {
           source_labels = ["__syslog_message_hostname"]
           target_label  = "hostname"
       }

       rule {
           source_labels = ["__syslog_message_severity"]                       
                         23:06 [25/1855]
           target_label  = "level"
       }

       rule {
           source_labels = ["__syslog_message_app_name"]
           target_label  = "application"
       }

       rule {
           source_labels = ["__syslog_message_facility"]
           target_label  = "facility"
       }

       rule {
           source_labels = ["__syslog_connection_hostname"]
           target_label  = "connection_hostname"
       }
   }

   loki.source.syslog "syslog_tls" {
       listener {
           address = "10.0.26.1:6514"
           protocol = "tcp"
           idle_timeout = "37m"
           use_rfc5424_message = true
           labels = { job = "syslog", component = "loki.source.syslog",
protocol = "tcp/tls" }
           max_message_length = 0

           tls_config {
               ca_file = "/usr/local/etc/alloy/SENSITIVE/certs/np-az.crt"
               cert_file = "/usr/local/etc/alloy/SENSITIVE/certs/alloy.crt"
               key_file = "/usr/local/etc/alloy/SENSITIVE/certs/alloy.key"
               min_version = "TLS13"
               server_name = "logs.vestertopia.net"
           }
       }

       forward_to    = [loki.process.syslog.receiver]
       relabel_rules = discovery.relabel.syslog.rules
   }

   loki.process "syslog" {
       stage.match {
           selector = "{application=\"devd\", level=\"debug\"}"
           action = "drop"
           drop_counter_reason = "devd debug"
       }

       forward_to = argument.forward_to.value
   }
}

========================

"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.

-- 
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-LLplW6mimJ>