Back to the hugo package... >hugo version hugo v0.160.1+extended+withdeploy openbsd/amd64 BuildDate=unknown
While we are using the extended hugo binary, OpenBSD manages system memory allocations (malloc) and system calls much more strictly than Linux or macOS (e.g., using W^X write-xor-execute protections). Because modern Hugo uses a compiled WebAssembly (WASM) virtual machine layer (libwebp translated via Go's internal warpc target) to process WebP images, the Hugo binary is attempting to dynamically allocate executable memory pages inside OpenBSD to compute the image resizing calculations. OpenBSD's kernel prevents this by default for security, instantly killing the internal thread and passing a generic failed to resize image error back to Hugo. Does this make sense now? On Monday, May 25th, 2026 at 5:32 PM, Otto Cooper <[email protected]> wrote: > The problem was traced down to the hugo theme, who is resizing images, and > the unerlying engine that performs such resizing. I see tickets out on github > that are discussing it. So, this is nothing I am doing directly and worth > discussing here. > > Ciao > > > -------- Original Message -------- > On Monday, 05/25/26 at 15:42 Kirill A. Korinsky <[email protected]> wrote: > On Mon, 25 May 2026 15:18:17 +0200, > Otto Cooper <[email protected]> wrote: > > > > Following the white rabbit down its hole, I see that httpd is just fine, > > while the problem is hugo 0.160.1 who is returning a timeout when calling > > Resize on a webp image. So the problem seems to be with the package hugo, > > as the webp is one years old and just fine with the previous package. > > > > Well, you may use hugo to statically compile your site in advance and server > it by httpd. > > If you use hugo server, when you need a wait because it uses caches, and I > almost sure that upgrade of hugo invalidated majority of them. > > Still, I suggest to share config and request which leads to 403, because it > looks very suspicious from that you explaning. > > -- > wbr, Kirill > > >
