Skip to main content

friendica - Link to source

utzer (on squeet.me)

This is a post to inform about some services planned downtimes. All services have the same downtime duration, or similar duration, but I can not update in de...
squeet.me
!Friendica Admins
in reply to utzer [Friendica]

utzer [Friendica]
friendica - Link to source
utzer [Friendica]
• •
postponed for another 8h at least.
in reply to utzer [Friendica]

utzer (on squeet.me)
friendica - Link to source
utzer (on squeet.me)
• •
@utzer [Friendica] running again now, need to check some things, then add the new drive to the raid, wait for sync, remove another SSD from the raid... but first I will have dinner, so maybe I will only continue tomorrow. I will update here.
This entry was edited (2 years ago)
in reply to utzer (on squeet.me)

utzer (on squeet.me)
friendica - Link to source
utzer (on squeet.me)
• •
There will be another 1 hour and 15 minute downtime today (27.02.2023) at 16:30 CET, last SSD exchange.
in reply to utzer [Friendica]

Philipp Holzer
friendica - Link to source
Philipp Holzer
• •

Hi @utzer [Friendica] , are there still troubles with the *.friendi.ca server?

I restarted the friendica.me instance, based on the develop branch and now I'm unable to build it again
- files.friendi.ca is down for the archives
- git.friendi.ca is down for the json-ld library

Unfortunately, I'm now stuck 😕

in reply to Philipp Holzer

utzer [Friendica]
friendica - Link to source
utzer [Friendica]
• •

@Philipp Holzer the server is running again, it crashed, nothing in the log, wr did a run of fsck. Should have done that before.

Now we need to wait again to see what happens. Dmesg is open and we're capturing the output.

@Philipp Holzer
in reply to utzer [Friendica]

Philipp Holzer
friendica - Link to source
Philipp Holzer
• •
Good luck finding the root - cause 🙁 🙁 I know how annoying such crash situations are
in reply to Philipp Holzer

Roland Häder🇩🇪
friendica - Link to source
Roland Häder🇩🇪
• •
@Philipp Holzer @utzer [Friendica] There should be some messages in php-fpm.log or syslog at least. Or do you have #systemd ? Then try reading its journal. A crash, mostly SEGFAULT means that there is an endless/recursive loop. I had this here. Try to reproduce it with strace php crashing-script.php (minimum) and also add a lot debug messages, e.g. which method is being invoked with which parameters (log them all). This is what I do and I was always very successful with it:
// Minimum (sometimes the only way in segfault situations):
printf('[%s:%d]: param1[%s]=%s - CALLED!' . PHP_EOL, __METHOD__, __LINE__, gettype($param1), $param1);

// Or with an actual logger
SomeLogger::trace(sprintf('param1[%s]=%s - CALLED!', gettype($param1), $param1);

Of course logging the type of the parameter makes only sense when you have a multiple-type e.g. string $param1 = null, then $param1 could be type of string or null.
#Systemd @Philipp Holzer
in reply to utzer [Friendica]

Roland Häder🇩🇪
friendica - Link to source
Roland Häder🇩🇪
• •
@utzer [Friendica] @Philipp Holzer Okay, maybe the on-error condition has made it read-only (default for most distris). errors=remount-ro is then the option, it is very highly recommended.
@Philipp Holzer

Lo, thar be cookies on this site to keep track of your login. By clicking 'okay', you are CONSENTING to this.

⇧