TempMussol

existing hub not recognized

Thu, 01 Nov 2018 10:13:54 -0400

tempmussol@narrow.world

!Hubzilla Support Forum Having solved my 502/504 problem with the able assisstance of @M. Dent, I now get the following when I go to my hub:

Hubzilla Server - Setup
  System check

I am running 3.6.1 and have not changed anything to do with Hubzilla config since it was last running. The restart was due to a full disk and that service mysql status at the time told me that the no space error happened while trying to write a database file though I can't remember which table. Possible corruption causing this?

show all 12 comments

Thu, 01 Nov 2018 11:20:16 -0400 last edited: Thu, 01 Nov 2018 11:49:35 -0400

TempMussol

tempmussol@narrow.world

The database is there:

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| hubzilladb         |
| information_schema |
| maildb             |
| mysql              |
| nextclouddb        |
| performance_schema |
+--------------------+
6 rows in set (0.00 sec)

But mysqlcheck hubzilladb gives me nothing (and not a stream of checked tables as I would expect). So I check /var/lib/mysql/hubzilladb and it's empty. What! I haven't deleted it (I would've remembered that).

edit: Not actually empty:

root@pendle:/var/lib/mysql/hubzilladb# ls -al
total 12
drwx------ 2 mysql mysql 4096 Oct 22 10:38 .
drwxr-xr-x 7 mysql mysql 4096 Nov  1 14:35 ..
-rw-rw---- 1 mysql mysql   65 Mar  8  2018 db.opt

I believe 08 March was the day I transitioned from RedMatrix to Hubzilla.

Thu, 01 Nov 2018 11:27:42 -0400

Philipp

philipp@kukka.uber.space

I had the same thing some days ago, without any obvious reason. At my server, .htconfig.php was missing and the system therefore thought it to be a new install.

Thu, 01 Nov 2018 11:44:31 -0400

TempMussol

tempmussol@narrow.world

My database seems to have completely disappeared:

MariaDB [(none)]> use hubzilladb;
Database changed
MariaDB [hubzilladb]> show tables;
Empty set (0.00 sec)

I am now officially panicking. I have definitely not dropped the db (or why would it still show in show databases;?) and I have definitely not deleted the files from /var/lib/mysql/.

Thu, 01 Nov 2018 12:05:44 -0400

cb7f604332cf39

cb7f604332cf39@hubzilla.eu

are the files still exist under /var/lib/mysql/ ?
Are the files corrupt?

Thu, 01 Nov 2018 12:08:52 -0400

TempMussol

tempmussol@narrow.world

I have been through the 1,000 commands each of the readline for bash and mysql and I have done nothing that would indicate I have done anything to delete Hubzilla. I am seriously confused and anxious.

Thu, 01 Nov 2018 12:45:11 -0400

Daniel

enp4s0@besaid.de

[wild guesses incoming]
Something may have gone wrong with mysql during the time when you were low on disk space. I remember something similar maybe ~8 years ago with mysql. For me that was just an inconvinience, as that database didn't contain any live data. I was also rather inexperienced with mysql at that time, so that memory may well be false.
Maybe the tables got corrupted. I believe Debian runs an automatic recovery when bringing the database up, so have another look at your logs, especially of the recovery after you free'd up some space.

Unless you have filesystems snapshots, you probably have to restore your backup of the database.

Thu, 01 Nov 2018 14:05:09 -0400

TempMussol

tempmussol@narrow.world

This is bad news. I do a daily backup that is rsynced to another box. However because the database completely disappeared rather than just wouldn't work because it was corrupted, I have been getting happy messages from the dbdump and rsync scripts as it dumps and copies nothing essentially.

I therefore have seven lovely backups of a non database. The "incident" happened over seven days ago.

I am completely baffled as to why a disk space problem would delete a whole multitable database and not just leave one table corrupted

Thu, 01 Nov 2018 15:07:41 -0400

M. Dent

dm42@my.hosted.social

My heart sank as I read your most recent message. I've been in those shoes, and there is nothing I can say to make it better at all. Hopefully, maybe, you have another backup to restore from?

I don't remember clearly enough the details about INNODB and MYSQL, but open write file descriptors and overwriting disk space typically do not play well together. It was likely the auto-repair that is ultimately to blame for deleting them. I try (though not always successfully) to turn stuff like that off - I want to remain in control of the "thinking" - and the machine to do my bidding. If a decision is involved - the system should wait for an operator to make it. Old School, I know. But from my own similar experiences, I know the ruthless efficiency of automation and "automatic defaults".

Thu, 01 Nov 2018 16:52:57 -0400

Daniel

enp4s0@besaid.de

Looking at this part...

root@pendle:/var/lib/mysql/hubzilladb# ls -al
total 12
drwx------ 2 mysql mysql 4096 Oct 22 10:38 .
drwxr-xr-x 7 mysql mysql 4096 Nov  1 14:35 ..
-rw-rw---- 1 mysql mysql   65 Mar  8  2018 db.opt

This means that the last time an entry (file, directory, link, ...) was added or removed from the directory /var/lib/mysql/hubzilladb was on Oct 22 at 10:38 and gives you a chance to find the incident in the logs.
Any file backup after that date will contain nothing.
If you've used mysqldump or similar, it might still make sense to check backups after that timestamp, in case mysql still had the database files open, but if it was an automatic recovery on service restart or a reboot it's rather unlikely.

Another thing to verify: Are all filesystems mounted?

Thu, 01 Nov 2018 17:56:49 -0400 last edited: Thu, 01 Nov 2018 18:01:58 -0400

TempMussol

tempmussol@narrow.world

The back up box is not mine. There is a possibility that the owner of it has a back up of my back up (preferably from between 0100 22 October when the database dump was rsynced and 1038 when the incident occured).

Fri, 02 Nov 2018 03:17:12 -0400

cb7f604332cf39

cb7f604332cf39@hubzilla.eu

I keep the fingers crossed.

Sun, 04 Nov 2018 17:11:12 -0500

elmussol

elmussol@elsmussols.net

Thank you to everyone who helped on this. Its seems that elsmussols.org is not retrievable. You live and learn. I will be relaunching as elsmussols.net shortly. I have written more on my own timeline.

502s and 504s

Sun, 28 Oct 2018 16:06:25 -0400

TempMussol

tempmussol@narrow.world

!Hubzilla Support Forum The box that elsmussols.org lives on runs Hubzilla, Nextcloud and a small email server. Something changed on Monday (?). I unfortunately let the hard disk fill, so cleared some space and restarted nginx, mysql (MariaDB) and php7.0-fpm services. Email is still working and the box is unstressed in terms of load and so on.

For both Hubzilla and Nextcloud I now get: 504 Gateway Time-out or 502 Bad Gateway when trying to access. A little DDGing tells me about editing nginx.conf and php.ini files adjusting various variables but I have two problems . A vast vast majority of the solutions were referring to PHP5.6 and I don't want to make assumptions about PHP7.0's behaviour and I have no idea how this mix of variables play with each other.

So help please from those who are using this combo successfully. TIA.

show all 22 comments

Sun, 28 Oct 2018 16:13:00 -0400

M. Dent

dm42@my.hosted.social

I'm using the same basic setup as you on my production server. What variables are you looking at and concerned about?

502 Bad Gateway is usually that it can't find the back end. Typically if you're using sockets - php-fpm's socket isn't there - if PHP-FPM is running over TCP/IP, then it isn't answering the phone. Just based on the errors, it looks to me like you may have each of them set up differently.

Quick check - is PHP-FPM actually running? (ps -ax)

Sun, 28 Oct 2018 16:19:08 -0400

TempMussol

tempmussol@narrow.world

It's running:

root@pendle:~# service php7.0-fpm status
â— php7.0-fpm.service - The PHP 7.0 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.0-fpm.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2018-10-28 20:07:38 CET; 1h 7min ago
     Docs: man:php-fpm7.0(8)
 Main PID: 679 (php-fpm7.0)
   Status: "Processes active: 5, idle: 0, Requests: 760, slow: 0, Traffic: 0.3req/sec"
    Tasks: 6 (limit: 4915)
   CGroup: /system.slice/php7.0-fpm.service
           â”œâ”€ 679 php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
           â”œâ”€2476 php-fpm: pool www
           â”œâ”€2500 php-fpm: pool www
           â”œâ”€2501 php-fpm: pool www
           â”œâ”€2612 php-fpm: pool www
           â””â”€2613 php-fpm: pool www

Oct 28 20:06:08 pendle systemd[1]: Starting The PHP 7.0 FastCGI Process Manager...
Oct 28 20:07:38 pendle systemd[1]: Started The PHP 7.0 FastCGI Process Manager.

And this is the relevant bit out of elsmussols nginx config:

fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Sun, 28 Oct 2018 16:27:38 -0400

TempMussol

tempmussol@narrow.world

And to answer your other question: I have seen howtos that talk about adjusting fastcgi_read_timeout, request_terminate_timeout, proxy_read_timeout in various measure.

Sun, 28 Oct 2018 16:54:46 -0400

TempMussol

tempmussol@narrow.world

This info may be useful:

root@pendle:~# cat /etc/nginx/sites-available/elsmussols.org | grep fast
fastcgi_param HTTPS on;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
# fastcgi_pass 127.0.0.1:9000;
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# fastcgi_read_timeout 300;

and

root@pendle:~# cat /etc/nginx/sites-available/nextcloud.elsmussols.net | grep fast
    fastcgi_buffers 64 4K;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param HTTPS on;
        fastcgi_param modHeadersAvailable true;
        fastcgi_param front_controller_active true;
        fastcgi_pass php-handler;
        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;

Sun, 28 Oct 2018 17:56:41 -0400

M. Dent

dm42@my.hosted.social

Status: "Processes active: 5, idle: 0, Requests: 760, slow: 0, Traffic: 0.3req/sec"

It looks like it's really busy (and a bit slow) playing catchup. 3 secs per request and 0 idle processes. It's trying hard to do something.

Probably more helpful (since clearly PHP-FPM is running) - what do your php-fpm.d/xxx.conf files look like?

Sun, 28 Oct 2018 19:05:05 -0400 last edited: Sun, 28 Oct 2018 19:08:20 -0400

TempMussol

tempmussol@narrow.world

M Dent wrote:

what do your php-fpm.d/xxx.conf files look like?

Not sure which files your looking for.

Edit
Do you mean /etc/php/7.0/fpm/php-fpm.conf and/or /etc/php/7.0/fpm/php.ini?

Sun, 28 Oct 2018 19:25:13 -0400

M. Dent

dm42@my.hosted.social

Depends on which distro you're using. It's probably /etc/php/7.0/fpm/php-fpm.conf - but php.ini might be helpful too.

Wed, 31 Oct 2018 15:23:32 -0400

TempMussol

tempmussol@narrow.world

Distro is Debian stable. Here are all uncommented lines for /etc/php/7.0/fpm/php-fpm.conf:

pid = /run/php/php7.0-fpm.pid
error_log = /var/log/php7.0-fpm.log
include=/etc/php/7.0/fpm/pool.d/*.conf

and /etc/php/7.0/fpm/php.ini:

engine = On
short_open_tag = Off
precision = 14
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = 17
disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,
disable_classes =
zend.enable_gc = On
expose_php = Off
max_input_time = 60
memory_limit = 192M
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
track_errors = Off
html_errors = On
variables_order = "GPCS"
request_order = "GP"
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 21M
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
default_charset = "UTF-8"
doc_root =
user_dir =
enable_dl = Off
file_uploads = On
upload_max_filesize = 20M
max_file_uploads = 20
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60
cli_server.color = On
pdo_mysql.cache_size = 2000
pdo_mysql.default_socket=
SMTP = localhost
smtp_port = 25
mail.add_x_header = On
sql.safe_mode = Off
odbc.allow_persistent = On
odbc.check_persistent = On
odbc.max_persistent = -1
odbc.max_links = -1
odbc.defaultlrl = 4096
odbc.defaultbinmode = 1
ibase.allow_persistent = 1
ibase.max_persistent = -1
ibase.max_links = -1
ibase.timestampformat = "%Y-%m-%d %H:%M:%S"
ibase.dateformat = "%Y-%m-%d"
ibase.timeformat = "%H:%M:%S"
mysqli.max_persistent = -1
mysqli.allow_persistent = On
mysqli.max_links = -1
mysqli.cache_size = 2000
mysqli.default_port = 3306
mysqli.default_socket =
mysqli.default_host =
mysqli.default_user =
mysqli.default_pw =
mysqli.reconnect = Off
mysqlnd.collect_statistics = On
mysqlnd.collect_memory_statistics = Off
pgsql.allow_persistent = On
pgsql.auto_reset_persistent = Off
pgsql.max_persistent = -1
pgsql.max_links = -1
pgsql.ignore_notice = 0
pgsql.log_notice = 0
bcmath.scale = 0
session.save_handler = files
session.use_strict_mode = 0
session.use_cookies = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.serialize_handler = php
session.gc_probability = 0
session.gc_divisor = 1000
session.gc_maxlifetime = 1440
session.referer_check =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = 0
session.hash_bits_per_character = 5
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"
zend.assertions = -1
tidy.clean_output = Off
soap.wsdl_cache_enabled=1
soap.wsdl_cache_dir="/tmp"
soap.wsdl_cache_ttl=86400
soap.wsdl_cache_limit = 5
ldap.max_links = -1
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=1
opcache.save_comments=1

Wed, 31 Oct 2018 22:14:19 -0400

M. Dent

dm42@my.hosted.social

One step closer - Now at least I know that the files I need are in the /etc/php/7.0/fpm/pool.d/*.conf files. There is probably one for Nextcloud and one for Hubzilla. If you can, also include your site files for nginx.conf - if you want you can PM me these - and/or take out any sensitive data. It should be relatively easy to find and fix.

Thu, 01 Nov 2018 06:11:10 -0400

TempMussol

tempmussol@narrow.world

There is one file in /etc/php/7.0/fpm/pool.d/, www.conf, so I assume that both Nextcloud and Hubzilla use the same. The uncommented lines in this file are:

user = www-data
group = www-data
listen = /run/php/php7.0-fpm.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Hubzilla nginx conf uncommented lines:

server {
listen 80;
server_name elsmussols.org;
index index.php;
root /var/www/hubzilla;
rewrite ^ https://elsmussols.org$request_uri? permanent;
}

server {
listen 443 ssl;
server_name elsmussols.org;
ssl on;
ssl_certificate /etc/letsencrypt/live/elsmussols.org/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/elsmussols.org/privkey.pem;

ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;
ssl_prefer_server_ciphers on;
fastcgi_param HTTPS on;
index index.php;
charset utf-8;
root /var/www/hubzilla;
access_log /var/log/nginx/hubzilla.log;

client_max_body_size 20m;
client_body_buffer_size 128k;

location / {
    if ($is_args != "") {
        rewrite ^/(.*) /index.php?q=$uri&$args last;
    }
    rewrite ^/(.*) /index.php?q=$uri last;
  }

location ^~ /.well-known/ {
allow all;
rewrite ^/(.*) /index.php?q=$uri&$args last;
}

location ~* \.(jpg|jpeg|gif|png|ico|css|js|htm|html|map|ttf|woff|woff2|svg)$ {
expires 30d;
try_files $uri /index.php?q=$uri&$args;
}

location ~* \.(tpl|md|tgz|log|out)$ {
deny all;
}

location ~* \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

location ~ /\. {
deny all;
}

location ~ /store {
deny all;
}
}

Nextcloud nginx conf uncommented lines:

upstream php-handler {
    server 127.0.0.1:9000;
    server unix:/var/run/php/php7.0-fpm.sock;
}

server {
    listen 80;
    listen [::]:80;
    server_name nextcloud.elsmussols.net;
    # enforce https
    return 301 https://$server_name$request_uri;

    location ^~ /.well-known/acme-challenge { allow all; }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name nextcloud.elsmussols.net;

    ssl_certificate /etc/letsencrypt/live/nextcloud.elsmussols.net/fullchain.pem;                                                                                               ssl_certificate_key /etc/letsencrypt/live/nextcloud.elsmussols.net/privkey.pem;

    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;

    root /var/www/nextcloud/;

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    location = /.well-known/carddav {
      return 301 $scheme://$host/remote.php/dav;
    }
    location = /.well-known/caldav {
      return 301 $scheme://$host/remote.php/dav;
    }

    location ^~ /.well-known/acme-challenge { allow all; }

    client_max_body_size 512M;
    fastcgi_buffers 64 4K;

    gzip on;
    gzip_vary on;
    gzip_comp_level 4;
    gzip_min_length 256;
    gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
    gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

    location / {
        rewrite ^ /index.php$uri;
    }

    location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
        deny all;
    }
    location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
        deny all;
    }

    location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param HTTPS on;
        #Avoid sending the security headers twice
        fastcgi_param modHeadersAvailable true;
        fastcgi_param front_controller_active true;
        fastcgi_pass php-handler;
        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;
    }

    location ~ ^/(?:updater|ocs-provider)(?:$|/) {
        try_files $uri/ =404;
        index index.php;
    }

    location ~ \.(?:css|js|woff|svg|gif)$ {
        try_files $uri /index.php$uri$is_args$args;
        add_header Cache-Control "public, max-age=15778463";
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Robots-Tag none;
        add_header X-Download-Options noopen;
        add_header X-Permitted-Cross-Domain-Policies none;
        access_log off;
    }

    location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
        try_files $uri /index.php$uri$is_args$args;
        access_log off;
    }
}

Thu, 01 Nov 2018 07:48:09 -0400 last edited: Thu, 01 Nov 2018 07:53:36 -0400

TempMussol

tempmussol@narrow.world

I am assuming from your expected response that:

I wrote:

There is one file in /etc/php/7.0/fpm/pool.d/, www.conf

is not best practice.

Thu, 01 Nov 2018 07:51:28 -0400

M. Dent

dm42@my.hosted.social

It can work, I prefer to have a xxx.conf file for each host/service.

Thu, 01 Nov 2018 08:03:30 -0400

M. Dent

dm42@my.hosted.social

There are a couple of things I see right off the bat. The fact that you have a single www.conf file means both services are sharing the same resources. Hubzilla needs WAY more than 5 in the max_child_process setting. I say 25 minimum. That could result in some of the behavior.

The other thing is the two server settings in your Nginx config for NextCloud

upstream php-handler {
 server 127.0.0.1:9000;
 server unix:/var/run/php/php7.0-fpm.sock;
}
/code]

It should be only the [code]server unix:...sock;

line according to the rest of your config. Php-fpm is not creating a tcp port. And next cloud is trying to connect that way.

I I'm not positive, but I think if you fix those two things, you'll at least make progress, and I think that may fix it entirely.

Thu, 01 Nov 2018 09:10:14 -0400 last edited: Thu, 01 Nov 2018 09:54:25 -0400

TempMussol

tempmussol@narrow.world

Thank you very much for these insights. I am assuming that max_child_process is pm.max_children.

I also assume that it is OK that both nginx config files to point to the same unix:foo socket.

I will make these changes and see where we are.

Thu, 01 Nov 2018 09:15:50 -0400

cb7f604332cf39

cb7f604332cf39@hubzilla.eu

I had some problems some weeks ago with php and fpm. I increased the max_child_process and reduced some timeouts to less than 30 sec.
And as an addtitional task I optimzed the database. Cleaned up some unused old accounts also.

Thu, 01 Nov 2018 09:54:01 -0400

TempMussol

tempmussol@narrow.world

Progress. By reading /var/log/php7.0-fpm.log and messing with values, I now have:

pm.max_children = 50
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12

Result: Nextcloud is now working. If I go to Hubzilla I get:

Hubzilla Server - Setup
  System check

I haven't changed any Hubzilla settings since this last worked. I shall investigate further.

Thu, 01 Nov 2018 10:06:19 -0400

TempMussol

tempmussol@narrow.world

I will start a separate thread for this as it's not related. Big kiss &/or hug &/or beer &/or coffee to @M. Dent for his insight and patience.

Fri, 02 Nov 2018 05:27:17 -0400

Mario Vavti

mario@hub.somaton.com

@TempMussol is you .htconfig present and readable by the server?

Sun, 04 Nov 2018 13:47:06 -0500

TempMussol

tempmussol@narrow.world

@Mario Vavti It seems to have been clobbered somehow:

root@pendle:/var/www/hubzilla# ls -al | grep config
root@pendle:/var/www/hubzilla#

Odd . I am sure you have a reason for asking.

Sun, 04 Nov 2018 13:50:22 -0500

TempMussol

tempmussol@narrow.world

Or to put it another way, why would it spontaneously disappear?

Sun, 04 Nov 2018 13:50:33 -0500

Mario Vavti

mario@hub.somaton.com

@TempMussol since i read in the other thread that your DB has been erased it does not actually matter anymore...

Sun, 04 Nov 2018 13:51:53 -0500

TempMussol

tempmussol@narrow.world

OK.

elsmussols.org update

Fri, 26 Oct 2018 19:26:42 -0400

TempMussol

tempmussol@narrow.world

!Hubzilla Support Forum Offline sorry. I will write more tomorrow when I have 20 seconds to spare. Ever have one of those months in a week?

elM

Sat, 27 Oct 2018 10:22:46 -0400

Michael

mike@narrow.world

:-(

Sun, 28 Oct 2018 15:53:04 -0400

TempMussol

tempmussol@narrow.world

Holy moly that was a week. But I am out the other side with most important tasks being accomplished and the only by-product is heavy sleep deprivation. See separate post coming in a few minutes about the actual problem.