• taladar@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    18
    ·
    6 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
      6 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
      6 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.

    • jetA
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      edit-2
      6 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
        ·
        6 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.

        • jetA
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          6 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