Conversation

Notices

  1. 1/7/2017 - the day Swedish programming made @takekiwiakenji @takekiwiakenji loose the last of his marbles

    Sunday, 08-Jan-17 01:45:04 UTC from sealion.club
    1. @fl0wn We really need a better _complete_ OStatus implementation.

      Sunday, 08-Jan-17 01:50:28 UTC from gs.kawa-kun.com
      1. @takeFrankerZakenji @fl0wn I heard your instance got broken, what happened? inb4 Markov has risen the other bots to take over the VDS.

        Sunday, 08-Jan-17 10:02:32 UTC from gs.smuglo.li
        1. @tijagi @fl0wn http://u.daggsy.com/H1

          Sunday, 08-Jan-17 15:30:38 UTC from gs.kawa-kun.com
          1. @takebananaakenji If you're still on php5.x try attaching a profiler to it.

            Sunday, 08-Jan-17 15:35:33 UTC from community.highlandarrow.com
          2. @takekiwiakenji @fl0wn 504 looks like a backend failure. E.g. php-fpm.

            Sunday, 08-Jan-17 15:40:15 UTC from gs.smuglo.li
            1. @tijagi @fl0wn As I've said a half-dozen times, nothing is obvious in the php-fpm logs, even with debugging cranked way up.  Same goes for GS logs.

              Sunday, 08-Jan-17 15:41:59 UTC from gs.kawa-kun.com
              1. @takeFrankerZakenji @fl0wn Do you have catch_workers_output set to yes in php-fpm.conf?

                I would also suggest to check, that
                display_errors = On
                display_startup_errors = On
                log_errors = On
                report_memleaks = On
                track_errors = On
                html_errors = On

                And possibly adjust log_errors_max_len to something bigger than 1024, e.g. to 15k.

                Sunday, 08-Jan-17 16:06:26 UTC from gs.smuglo.li
                1. @tijagi @fl0wn I don't think I want to mess around with the ones that the documentation says to leave disabled for production systems.

                  Sunday, 08-Jan-17 16:20:12 UTC from gs.kawa-kun.com
                  1. @takePotato Knishesakenji @fl0wn I suppose you’re talking about display_* ones? But if you want to debug a production system, you have to close it from the outer world anyway. If you don’t want to debug, you can wait that this cuckcoding will be fixed by itself someday™. But don’t ask people for help then. https://gs.smuglo.li/attachment/265848

                    Sunday, 08-Jan-17 17:10:10 UTC from gs.smuglo.li
                    1. @tijagi @fl0wn Thing is, a GS node is part of a network.  If you close it off, not only does it become useless, it also is in an unrealistic environment.  Testing in an environment that doesn't reflect real-world use to a significant degree is a waste of time, and you should know that.

                      Sunday, 08-Jan-17 17:12:17 UTC from gs.kawa-kun.com
                      1. @fl0wn @tijagi Try running your own instance for a while before dictating to me from on high like that.

                        Sunday, 08-Jan-17 17:13:03 UTC from gs.kawa-kun.com
                      2. @takeappleakenji @fl0wn Well, discard display_* options. Others are safe to enable, they only enable full-fledged logging. It may consume more I/O, but otherwise shouldn’t affect the interaction with the GS instance.

                        Sunday, 08-Jan-17 17:18:13 UTC from gs.smuglo.li
              2. @takemangoakenji In at least five years of running SN/GS instances, I've always felt that # / # logs resemble #'s logging. Far too much info, but never enough about the actual problem you're investigating.

                Sunday, 08-Jan-17 16:26:06 UTC from n2.federati.net
                1. @n2admin Most logging systems are like that.

                  Sunday, 08-Jan-17 16:29:31 UTC from gs.kawa-kun.com