Hugo: Timed out creating content

[brunoamaral]

My content/ folder is around 1.9 GB and last night I deleted the resources/ folder to generate the images again. It was taking forever and the hugo process was not taking up any memory or cpu. When I ran the command in verbose mode, it gave me this error message:

WARN 2018/06/10 16:23:12 WARNING: Timed out creating content for page "stories/museum-tour/2018-02-13-Museu-Nacional-Arte-Antiga/index.md" (.Content will be empty). This is most likely a circular shortcode content loop that should be fixed. If this is just a shortcode calling a slow remote service, try to set "timeout=20000" (or higher, value is in milliseconds) in config.toml.

I did set the timeout value, ran it again, and another page was giving out that error with the process also appearing to be stalled.

My guess was that generating images was taking too long because there were so many of them pending. Running Hugo a few times eventually made it build as expected.

[brunoamaral]

Just went back to see what the pages giving error had in common, and they all use a shortcode with this instruction:

{{ range (.Page.Resources.Match (printf "%s*" (.Get "folder"))) }}
  {{ $thumbnail := .Resize "320x" }}

    <figure itemscope itemtype="http://schema.org/ImageObject" class="image gallery-item">
      <a href="{{ .Permalink }}" itemprop="contentUrl" data-size="{{ .Width }}x{{ .Height }}" >
          <img src="{{ $thumbnail.Permalink }}" itemprop="thumbnail" alt="galleryImage" class="galleryImage" />
      </a>
      <figcaption itemprop="caption description">
        <span itemprop="copyrightHolder"></span>
      </figcaption>
    </figure> 
{{ end }}

[aitva]

I have just hit the same issue. Hugo is working fine on my development machine but hangs forever in the CI pipeline. I have a smaller content folder than @brunoamaral, mine is only 8MB.

Here is the warning displayed with --verbose:

WARN 2018/09/05 16:31:40 WARNING: Timed out creating content for page "blog/travail-equipe-erreurs/index.md" (.Content will be empty). This is most likely a circular shortcode content loop that should be fixed. If this is just a shortcode calling a slow remote service, try to set "timeout=20000" (or higher, value is in milliseconds) in config.toml.

And here is the shortcode used by the page:

{{ $base := .Page.Resources.GetMatch (.Get "name") }}
<figure class="{{ .Get "class" }}">
    <picture>
        {{ $img := $base.Resize "600x" }}
        <source media="(max-width: 599px)" srcset="{{ $img.RelPermalink }}">
        {{ $img := $base.Resize "1024x" }}
        <source media="(min-width: 600px) and (max-width: 1023px)" srcset="{{ $img.RelPermalink }}">
        <source media="(min-width: 1024px)" srcset="{{ $base.RelPermalink }}">
        <img src="{{ $base.RelPermalink }}" alt="{{ .Get "alt" }}">
    </picture>
</figure>

Sometimes, I get multiple warning for different files before Hugo hangs. I can gather more information if needed.

[sharmay]

I am getting similar error.

Error: Error building site: "/post/commit-logs/mycomits.md:1:1": timed out initializing value. This is most likely a circular loop in a shortcode

In my .md file, I have 12270 code blocks using

{{< highlight txt "Style=solarized-dark256" >}}
....
{{< /highlight >}}

[liara]

@sharmay thanks for your comment. Run into the same issue with hugo v0.55. It also time outed on a .md file with lots of code. I was using Pygments, so I tried with the default Chroma and now the site builds fine and also fast.

pygmentsUseClassic = false

[sharmay]

@liara default is pygmentsUseClassic = false and I have not changed that, still using chroma.

[rwieruch]

I am running into the same issue lately and setting pygmentsUseClassic = false did the trick for me. What has changed for it?

[oveddan]

I have the same issue when deploying on Netlify. I've pinned it down to release 0.58.1
When I set version to 0.57.2 the error does not occur, but at 0.58.1 it does occur.

The shortcode that causes the error has the following in it:

{{ $original := .Page.Resources.GetMatch (printf "%s*" (.Get "src")) }}

{{ if $original }}
  {{ .Scratch.Set "image" ($original.Resize "700x") }}

  {{ $image := .Scratch.Get "image" }}

  <figure>
    <a href='{{ $original.RelPermalink }}' data-modal>
      <img src="{{ $image.RelPermalink }}" style="width:100%"/>
    </a>
    {{ if .Get "caption" }}
      <figcaption>
        {{.Get "caption"}}
        {{ if .Get "captionLink" }}
        <a href='{{ .Get "captionLink" }}'>{{ .Get "captionLinkText" }}</a>
        {{ end }}
      </figcaption>
    {{ end }}
  </figure>
{{ end }}

[oveddan]

Increasing my timeout just resolve the issue.

In my config.toml I set:

timeout = 60000

and it successfully builds on netlify.

[zaari]

After upgrading to Hugo v0.60 increasing timeout doesn't help anymore.

[bep]

@zaari hmm... that is odd. Can you try timeout = "30s" or something. I changed to also support duration strings (30s = 30 seconds etc.) and there may be glitch in that logic.

[zaari]

@bep Replacing timeout: 240000 with timeout: 240s (yaml) fixed the issue, so the site builds without errors now. Thanks.

[simar7]

I'm running into this recently as well.
2020-08-08T01:03:12.0045225Z Error: Error building site: "/home/runner/work/content/nvd/CVE-2016-2478.md:1:1": timed out initializing value. You may have a circular loop in a shortcode, or your site may have resources that take longer to build than thetimeoutlimit in your Hugo config file.

It works fine on my macOS local setup just fine but fails on a ubuntu CI runner. The shortcode before this started to happen and now hasn't changed so I'm kinda clueless as to what's going on. Increasing the timeout (to 60000) just makes the build run forever and eventually get killed by the CI timeout.

Any ideas as to what I can try?

[simar7]

Some more insight: The biggest markdown I render is 20K in size and I have lots of pages (~150000).

[simar7]

What I'm interested in knowing is that if this is considered a fatal error or not. By that I mean if I ignore the error in my CI would I still get the rest of the pages generated or does it just fail out right away when this error happens?

[simar7]

Another update: If I change my CI builder to use macOS it also works fine in the CI. So I'm guessing this is somehow isolated to the ubuntu-18.04 target.

I'm using GitHub Actions for the CI https://docs.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners#supported-runners-and-hardware-resources