user-1: I am running c-lightning with a pruned bitcoind backend. Every day at around the same time, c-lightning asks for a specific block which is already pruned, which looks like this in the logfile (block 540574 in this case):
2021-07-25T10:06:49.026Z UNUSUAL plugin-bcli: bitcoin-cli -rpcuser=... -rpcpassword=... getblock 00000000000000000010b0d763e1835bdb9921ae4b8adbb6d88d8cfcfbc392aa 0 exited with status 1

According to this comment from Christian, it is safe to ignore this warning. But because it appears every second in the logs and it feels spammy, I restart c-lighting and the error is gone until the other block (block 564180) is missing. Then I get the same message in the logs but for block 564180, also at around the same time every day.
I am pretty sure the two blocks have nothing to do with each other and also the blocks are probably specific to a channel (or two) I've opened with my node. So my question in the title is maybe a little bit misleading. That it happens with two blocks is probably also just a coincidence. But what my "real" questions are:

Why is the error gone after a restart? Does c-lightning "forget" it wanted to know about that specific block?
Why does the error appear at around the same time every day?

If this isn't the place to ask this, please tell me! I thought about opening an issue on github. Wasn't sure about this.

user120: There is nothing special about those two blocks, aside from containing a funding transaction that c-lightning would like to verify (causing it to look the block up) and it being pruned in your bitcoind.
Restarting indeed results in the lookup, which is kept in memory until it succeeds or fails, is forgotten giving you the temporary result of no longer spamming the logs. But once a peer tells you about the channel your node will resume it's attempts to verify it. Nodes will send updates every once in a while to update the fees on channels, but i think what you're seeing is a keepalive: a regularly scheduled update that is used to tell the network the channel is not stale/zombie and can be used. This is because you mention it reappearing once a day.
As for a permanent solution I suggest either looking into a Bitcoin backend that supports pruned nodes (bcli shipped with c-lightning doesn't support pruned nodes yet), or use btc-rpc-proxy in front of bitcoind to fetch missing blocks on demand (I personally use this with my nodes wherever I can't have full nodes sitting next to the lightning nodes).

-1: <p>I am running c-lightning with a pruned bitcoind backend. Every day at around the same time, c-lightning asks for a specific block which is already pruned, which looks like this in the logfile <em>(block 540574 in this case)</em>:</p>
<pre><code>2021-07-25T10:06:49.026Z UNUSUAL plugin-bcli: bitcoin-cli -rpcuser=... -rpcpassword=... getblock 00000000000000000010b0d763e1835bdb9921ae4b8adbb6d88d8cfcfbc392aa 0 exited with status 1
</code></pre>
<p>According to <a href="https://github.com/ElementsProject/lightning/issues/4174#issuecomment-721037362" rel="nofollow noreferrer">this comment</a> from Christian, it is safe to ignore this warning. But because it appears every second in the logs and it feels spammy, I restart c-lighting and the error is gone until the other block <em>(block 564180)</em> is missing. Then I get the same message in the logs but for block 564180, also at around the same time every day.</p>
<p>I am pretty sure the two blocks have nothing to do with each other and also the blocks are probably specific to a channel (or two) I've opened with my node. So my question in the title is maybe a little bit misleading. That it happens with two blocks is probably also just a coincidence. But what my &quot;real&quot; questions are:</p>
<ol>
<li>Why is the error gone after a restart? Does c-lightning &quot;forget&quot; it wanted to know about that specific block?</li>
<li>Why does the error appear at around the same time every day?</li>
</ol>
<p>If this isn't the place to ask this, please tell me! I thought about opening an issue on github. Wasn't sure about this.</p>
 120: <p>There is nothing special about those two blocks, aside from containing a funding transaction that c-lightning would like to verify (causing it to look the block up) and it being pruned in your <code>bitcoind</code>.</p>
<p>Restarting indeed results in the lookup, which is kept in memory until it succeeds or fails, is forgotten giving you the temporary result of no longer spamming the logs. But once a peer tells you about the channel your node will resume it's attempts to verify it. Nodes will send updates every once in a while to update the fees on channels, but i think what you're seeing is a keepalive: a regularly scheduled update that is used to tell the network the channel is not stale/zombie and can be used. This is because you mention it reappearing once a day.</p>
<p>As for a permanent solution I suggest either looking into a Bitcoin backend that supports pruned nodes (bcli shipped with c-lightning doesn't support pruned nodes yet), or use <a href="https://github.com/Kixunil/btc-rpc-proxy" rel="nofollow noreferrer">btc-rpc-proxy</a> in front of bitcoind to fetch missing blocks on demand (I personally use this with my nodes wherever I can't have full nodes sitting next to the lightning nodes).</p>
