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