From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4hxjVr1j1Nz2xXT for ; Sat, 03 Oct 2026 11:05:40 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "YR2" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4hxjVd1tFgz2xLt for ; Sat, 03 Oct 2026 11:05:29 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (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) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4hxjVZ1BTqz32C; Sat, 03 Oct 2026 11:05:26 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1791025526; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bKDCI0+fDPgbEEfe/+kRiKMli6JvvugDbNn8/xW2qyo=; b=00CHEmjInjDnMJYnQHKUNJtdtVQumfZVe2XP3nlDBl8QsdFRn+fh/EPpfzX4HK99WGfcOb oKBYQsxUA/UwL3Dw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1791025526; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bKDCI0+fDPgbEEfe/+kRiKMli6JvvugDbNn8/xW2qyo=; b=r4D6rOU2rCge04SDdnqYc+OEikuXgySINAko44VIFGO6hK+UMJPA7hW5baBJJH0QegSbv9 vymEXdjx/ROVs0hVneNs2qn+cZcTPAoqHuU9kOSg8KAui6qHE3aoAO4uKuVUleQjDKkuUS DUFQcwYv4LD/gSzLZ049eII+fSq6MVIcgmS+qLtFRz/0K5f7BKLLN1JGL/q0q38kfSw7Hk h8n5qLin0uQPrPEjyC5G3BPwt2+2iyegWHYlWlRh8xfPjnFE6ah7d/18OzM54oRJBHJKX8 QTYLZ0nV4C0t5d9xhWyA/+C3qlgIYaAzEJHX+I3+eIRNFg8JhUg8TjQkUo9Nmw== Message-ID: <2db5bb42-791b-4ca9-80c4-008cdab78761@ipfire.org> Date: Sat, 3 Oct 2026 13:05:25 +0200 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Subject: Re: knot-resolver 6.5.0 Content-Language: en-US To: Michael Tremer References: Cc: "IPFire: Development-List" From: Matthias Fischer In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 03.10.2026 11:57, Michael Tremer wrote: > Hello Matthias, Hi Michael, > Thanks for the update. No problem - it just came my way. ;-) > It seems like the supervisor process wants to create a “logs” directory inside another directory. Yep. Thats the way it looks like. But where? What that is, is hard to tell from the trace, but there cannot be many possible options. What permissions does /var/log/knot-resolver have? I suppose it cannot write to it. Sorry, but there is no such directory. The only *logging* option I can find is in 'config.yaml': ***SNIP*** # Enable logging logging: level: info target: syslog ***SNAP*** And as I see it, everything is logged to '/var/log/messages'. Some thoughts: The line containing to the 'generic exception' refers to something like 'config_store'(rather often), 'config' or 'write_config_file' ending with 'self._accessor.mkdir' resulting in 'PermissionError' but you never get a clue where this 'directory'(!?) is missing or where it should be... Frustrating. And the current documentation ends with version 6.4.2 (https://www.knot-resolver.cz/documentation/latest/NEWS.html). Hm! Best Matthias > -Michael > >> On 3 Oct 2026, at 09:59, Matthias Fischer wrote: >> >> Hi all, >> >> as always, I'd like to have a problem during updates - perhaps 'someone' >> has a clue? >> >> This time its 'knot-resolver 6.5.0' who refuses to start. Compiling and >> building was ok - no seen problems. >> >> But after updating, 'knot_resolver.manager.server' runs into an >> "uncaught generic exception during manager inicialization[sic]", >> throwing a looong line, ending in "PermissionError: [Errno 13] >> Permission denied: 'logs'". What does this "'logs'" mean? A directory? >> Where should it be? >> >> If 'someone' has the time to take a closer look, I attached a short >> excerpt of the logfile plus my current lfs and rootfile. >> >> Some thoughts: For building and compiling of the previous versions the >> 'setcap'-command for 'kresd' in lfs is needed. With 'v6.5.0' there is a >> additional binary - 'usr/bin/kres-manager'. Whatever this one is good >> for, could it be that something similar 'setcap'-command or some >> config-option for the 'meson setup' is needed here? I searched in >> 'meson_options.txt' (Configuration options) but didn't find something >> suitable. >> >> I would be very thankful for any hints... >> >> Best >> Matthias >>