• qprimed@lemmy.ml
    link
    fedilink
    English
    arrow-up
    9
    ·
    5 months ago

    “have you tried swtching it off and on again” solves 90% of support requests - at least for a little while ;-)

    • taladar@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      17
      ·
      5 months ago

      It solves virtually none of them, it is pretty good at destroying all the evidence needed to actually fix the problem for good though.

      • Sabata11792@kbin.social
        link
        fedilink
        arrow-up
        15
        ·
        edit-2
        5 months ago

        I don’t have 40 hours to dedicate to a single error message that pops up only on Tuesdays during a full moon and Jeff just needs to print his stupid report.

      • qprimed@lemmy.ml
        link
        fedilink
        English
        arrow-up
        6
        ·
        edit-2
        5 months ago

        we are not talking about backend systems here.

        we are talking about user devices in the wild, likely in an unknown state, with highly variable usage patterns by the user. someone with experience can usually determine how deeply to poke based on 30 seconds of questioning the user.

        “reboot” is absolutely valid when the issue is trivial, non-recurring and the equipment is not sensitive. if a reboot destroys logs then the device was not important to you to begin with.

      • jet@hackertalks.com
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        1
        ·
        edit-2
        5 months ago

        My experience has been the exact opposite of this.

        Restarting a system gets it into a known state making debugging easier.

        There are times you don’t want to restart, if your a software developer and a long lived process is behaving erratically and you haven’t been able to figure out why via telemetry and this problem has been super hard to reproduce… But this is a very niche and rare circumstance. Most scenarios the first priority is to get things working ASAP, so the first thing you do is restart.

        Hell, many production systems restart periodically to just get closer to a known good state as a matter of hygiene.

        • taladar@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          3
          ·
          5 months ago

          Restarting a system gets it into a known state making debugging easier.

          And what are you going to debug when the problem does not occur and you do not know how to reproduce it? There is a lot of information you can only gather while the problem occurs. And yes, this is from the software developer and sysadmin perspective, not from the layman perspective. I would rather spend a little bit more time on the problem now instead of having it occur again and again without getting any closer to an actual solution.

          • jet@hackertalks.com
            link
            fedilink
            English
            arrow-up
            1
            arrow-down
            1
            ·
            5 months ago

            The first piece of information you get is : does the problem persist beyond a restart

            Every investigation takes time, I’m glad that your able to satisfy yourself with in depth investigations when necessary.

            For non-life critical systems, the average protocol is to restart and see if it persists and only debug if the issue becomes problematic