docsy: failed to resolve output format "print" from site config

Following the getting started instructions, I get the following error:

$ docker-compose up
Creating network "mydocs_default" with the default driver
Creating mydocs_site_1 ... done
Attaching to mydocs_site_1
site_1  | Error: from config: failed to resolve output format "print" from site config
mydocs_site_1 exited with code 255

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Comments: 28 (6 by maintainers)

Most upvoted comments

Similar to ivan3bx, I did the following to resolve this issue:

sudo rm -rf $TMPDIR/hugo_cache/

Then rerun the Hugo server command.

hugo server -D

I’ve only been using docsy a few weeks, but encountered this same error. I found reference to “failed to resolve output format” elsewhere (external link), and I was able to fix with the following (Mac Mini, i7 MacOS 12.4, uptime 18+ days):

  1. Removed $TMPDIR/hugo_cache/ (per the troubleshooting article above. (NOTE: I needed to “sudo” this.)
  2. Re-ran hugo serve which worked fine. (i.e. no reboot)

Given the above, there might be a correlation between people resolving this via a reboot, and the OS doing housecleaning of the TMP dir as part of a reboot. Hard to say. Given how I was able to fix it, suggests this issue may have something to do with hugo’s handling of its mod cache, or Mac’s handling of tmp dirs.

Deleting the cache as per rachfop worked for me, and I did not have to change the config or any of the other suggestions. Thanks Patrick!

For everyone’s awareness, while I initially thought the fix for this seemingly random Mac issue is an OS upgrade, that is not the case. This error creeps up randomly after a few weeks on my machine and then a system restart fixes it.

The reason it worked before was because I did a system restart as part of the OS upgrade process. Not familiar enough with Hugo to guess why this error creeps up now and then and why a restart fixes it. But this problem started with the “Docsy as a Hugo Module” move. Didn’t have this issue when I was using Docsy as Git submodule.

Yup, I’ve had the print error continue to show back up every few days. I’m not sure why a restart fixes it. A colleague has also encountered this issue, but she’s not on an M1. Running Hugo/docsy in a docker container on her machine worked.

Related to https://github.com/google/docsy-example/issues/166.

I think there’s something else going on here. I was able to get things working just fine with docker-compose up --build, but hugo and hugo server fail with

Error: from config: failed to resolve output format "print" from site config

I’m wondering if the config changes are just false positives for some deeper issue, maybe something related to the hugo module or versions? I’m also having this problem locally, but a GitPod instance is not. Here’s the info:

GitPod (no problems with hugo server)

gitpod /workspace/openy_docs (main) $ go version
go version go1.18.1 linux/amd64
gitpod /workspace/openy_docs (main) $ hugo version
hugo v0.96.0+extended linux/amd64 BuildDate=unknown

Local:

❯ go version
go version go1.18.2 darwin/arm64
❯ hugo version
hugo v0.98.0+extended darwin/arm64 BuildDate=unknown

I also tried the challenging process of downgrading my local Hugo, but even with the versions identical that didn’t resolve the issue on my local.

Commenting out github_branch and removing the print option threw failed to extract shortcode: template for shortcode "blocks/cover" not found, but that also seems like a red herring.