Debian 10 - Hugo extended binary - No root access : how to work?

support
1

Hi

First of all, I would like to thank for the team building Hugo. Exactly what I was looking for ! Thanks !

I have a hosted website with SSH access but no root (that means no ability to use dpkg…). It uses Debian 10 buster.
I need the extended version of Hugo as I use image processing.

If I install hugo_extended_0.96.0_Linux-64bit.deb (with dpkg-deb -x) or hugo_extended_0.96.0_Linux-64bit.tar.gz, executing hugo gives an error :

runtime/cgo : pthread_create failed: Resource temporarily unavailable

followed by a stack…

I tried different versions (0.96 0.55…) without success.

Did I miss something ?
Thanks in advance

2

Hi,

without root access, you shouldn’t be able to install .deb packages.

Two solutions:

  • contact your host and request this installation
  • check your requirements and potentially switch to another solution based on github/gitlab CI.
    I’m using the free hosting from Gitlab and it works fine. Here is an example of a config file for Hugo Extended: .gitlab-ci.yml · main · roneo.org / Hugo Gallery · GitLab
3

Hi,

Thanks for your reply.
I understand the problem with package installation.

I use the Gitlab CI. But as it’s a genealogy site with lots of documents, the whole site is very heavy to my host (I’d rather prefer this way to Gitlab pages)… So I try to install a workflow on my host.

But the point is also with the .tar.gz archive.
If I download and extract the “regular” version of Hugo no problem.
If I download and extract the “extended” version, I got the crash.

Using the.tar.gz archive lets me putting the hugo executable where I need.

I think there’s a problem only with the extended version.

  • Is there an environment variable to set ?
  • Is there some hugo’s configuration to put ?

Thanks in advance

4

What is the output from:

ldd $(which hugo)

But I’m also curious… why do you need to install Hugo on your web server?

5

Hi

Here is what I’ve done :

 wget https://github.com/gohugoio/hugo/releases/download/v0.96.0/hugo_extended_0.96.0_Linux-64bit.tar.gz
tar zxvf hugo_extended_0.96.0_Linux-64bit.tar.gz
which hugo (no response)
./hugo version

The last command causes crash beginning with :

runtime/cgo: pthread_create failed: Resource temporarily unavailable
runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort
PC=0x7fdc502897bb m=3 sigcode=18446744073709551610

goroutine 0 [idle]:
runtime: unknown pc 0x7fdc502897bb
stack: frame={sp:0x7fdc28c19810, fp:0x0} stack=[0x7fdc2841a278,0x7fdc28c19e78)
0x00007fdc28c19710:  0x0000000000000000  0x0000000000000008
0x00007fdc28c19720:  0x0000000000000007  0x0000000000000000

Why do I need ?
1- I have other websites on my host and I like to have one point and not on my host, Gitlab…
2- Having a lot of documents (>300Mo) running hugo command needs to access the file (extracting Exif, resize for thumbnails…). So I have to put those files on Gitlab repo and then send on my host… Not very efficient…
3- I have my whole document management on my host with shell routines since many years.
4- I have also shell / perl routines to access my genealogy data (individuals) and link the both parts (documents with hugo and individuals data).

By the way here’s the output of file hugo :

hugo: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, Go BuildID=bBjo2xxDI6R2tgAckb3s/lF4fmPjr5JV1VrFbi1yE/3yfQF_TIaqrja6TXR9lV/ggVo7kWq1T0SC3hMLHar, BuildID[sha1]=5d263819ed806aa3faed109ad23a35756be47319, stripped

And archreturns x86_64.
And uname -a returns infong349 4.4.302-icpu-083 #2 SMP Fri Feb 18 09:10:21 UTC 2022 x86_64 GNU/Linux
And lsb_release -d returns

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster
6

What is the output from:

ldd [path-to-hugo-executable]
7

ldd [path to hugo executable] returns

        linux-vdso.so.1 (0x00007ffe3b5db000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1f36c3c000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1f36ab8000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1f36935000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1f36930000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1f36916000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1f36756000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1f36c67000)
8

What is the output from:

ls -l /lib/x86_64-linux-gnu/libpthread.so.0
9

It’s a link to libpthread-2.28.so

10

What are the permissions?

ls -l /lib/x86_64-linux-gnu/libpthread-2.28.so
11

-rwxr-xr-x 52 root root 146968 Mar 15 23:48 /lib/x86_64-linux-gnu/libpthread-2.28.so

12

That looks fine to me. Other than changing your hosting setup (which seems complicated and restrictive), maybe you can find a similar situation:

https://www.google.com/search?q=runtime%2Fcgo+%3A+pthread_create+failed%3A+Resource+temporarily+unavailable

13

Thanks for taking time for analyzing the situation.

I will find a way but I was surprised by the fact that only the extended version doesn’t run. That’s why I put a post.

I will have a look at the search.

Thank you

14

The extended version, at least on Nix, uses dynamically linked libs.

15

That’s an explanation. I’ll contact the hosting company. It looks like limits on number of threads…
At the beginning I thought it was an incompatibility with Debian 10…although it may be surprising.