4 ms·

Which is actually about IPv6 networking peculiarities/issue within a VMware, just fyi.

by imrehg 11y ago

chris_wot 11y ago
Uh... but why?!?
- atemerev 11y ago
  Software is unreliable. Bugs happen. Always. There are bugs in avionics, medical devices firmware, nuclear power plants monitoring software, bank transfers backends, all places. Once upon a time it was common to think that we can design software without bugs, or at least almost. That didn't work at all! What did work is redundant systems, invariant testing and fail-fast with restarts. This is how reliable systems are written these days. Bugs are common; we have to learn to work around them.
  - mikewilliams 11y ago
    /* fixed nullreferenceexception based on black box crash report */
    - cordite 11y ago
      void segfault_sigaction(int signal, siginfo_t *si, void *arg) { //Pretend it never happened return; }
      - atemerev 11y ago
        Of course, the only right way is panic() and wait for supervisor to restart the process / VM. Idiomatic Erlang doesn't differentiate between "system" / "environment" errors and local bugs. If it has failed — restart it!
        geofft 11y ago
        I'll bite. What about Erlang makes it so that a restarted process doesn't run into the same bug when it gets to the same point, and panic again in an infinite loop? The only way I can imagine this working is if Erlang is so buggy and nondeterministic that it inserts crashes sometimes but not all of the time. But that's obviously absurd.
        cordite 11y ago
        Wondered this too, it naively only makes sense for that case with neutrinos screwing your RAM over.
        liveoneggs 11y ago
        see section 3.4 here: http://erlang.org/documentation/doc-4.9.1/doc/design_principles/sup_princ.html http://erlang.org/documentation/doc-4.9.1/doc/design_princip... "3.4 The Restart Frequency Limit Mechanism"
        geofft 11y ago
        Well, okay, so your process crashes, you restart it, it crashes a few more times, then you kill it. What's the advantage there? How does this increase availability, beyond killing it the first time it crashes? It seems actively worse to allow users to retry requests that are doomed to failure than to put up a fail-whale or similar while the ops team is being paged.
        atemerev 11y ago
        Because most production bugs are infrequent (otherwise they would be noticed by testing). They have to be logged and fixed, but not allowed to move the system into inconsistent state. Restart first, fix later.
        geofft 11y ago
        Are they? The bug discussed in this comment was extremely deterministic. There's a difference between infrequent in the sense that, across lots of users and lots of requests it happens rarely, and infrequent in the sense that, for one particular use, it only triggers sometimes. Also, the bug discussed in this article wasn't causing crashes. What would you propose be crashed and restarted in this case?
  - chris_wot 11y ago
    > Bugs are common; we have to learn to work around them. Or we could, you know, fix them. I wasn't asking for a justification. I was just asking why this is occurring. If you don't know, that's cool. I mean, one of the reasons I ask is because I'd like to know if VMWare are going to fix this bug. So thank you for explaining that software has bugs. I'm sure I'll remember that the next time I fix a regression in LibreOffice, as I did with the issue with EMF dashed lines not displaying correctly or when I fixed the issue where JPEG exports didn't export the DPI value correctly...
    - mikeash 11y ago
      Just for future reference, something like "Do we know exactly what the bug in VMWare is, and whether they're going to fix it?" would be way more effective at getting the answer you're looking for here. "Uh... but why?!?" sounds like cursing at the sky, and gets a response appropriate for that.
      - chris_wot 11y ago
        Fair point.
- deleted 11y ago
  [deleted]
deleted 11y ago
[deleted]
pilif 11y ago
I'mm successfully running IPv6 on VMWare (Fusion, ESX 5, ESX 6) on both Clients (Debian 8, Ubuntu 12.04, FreeBSD 10.2, Windows 7, Windows 10) and Servers (Debian 8, Ubuntu 12.04, FreeBSD 10.2, Windows 2008R2) . I have not seen the issue described here in any configuration - neither on clients nor on servers. I wonder whether this is an issue with VMWare running on a specific host? edit: From the forum post in the linked article, I'm gathering they are using IPv6 NAT. So this might be a problem with the VMWare NAT interface - my configurations are all bridged.

Which is actually about IPv6 networking peculiarities/issue within a VMware, just fyi.

by imrehg 11y ago

Which is actually about IPv6 networking peculiarities/issue within a VMware, just fyi.

chris_wot 11y ago

Uh... but why?!?

atemerev 11y ago
Software is unreliable. Bugs happen. Always. There are bugs in avionics, medical devices firmware, nuclear power plants monitoring software, bank transfers backends, all places. Once upon a time it was common to think that we can design software without bugs, or at least almost. That didn't work at all! What did work is redundant systems, invariant testing and fail-fast with restarts. This is how reliable systems are written these days. Bugs are common; we have to learn to work around them.
- mikewilliams 11y ago
  /* fixed nullreferenceexception based on black box crash report */
  - cordite 11y ago
    void segfault_sigaction(int signal, siginfo_t *si, void *arg) { //Pretend it never happened return; }
    - atemerev 11y ago
      Of course, the only right way is panic() and wait for supervisor to restart the process / VM. Idiomatic Erlang doesn't differentiate between "system" / "environment" errors and local bugs. If it has failed — restart it!
      - geofft 11y ago
        I'll bite. What about Erlang makes it so that a restarted process doesn't run into the same bug when it gets to the same point, and panic again in an infinite loop? The only way I can imagine this working is if Erlang is so buggy and nondeterministic that it inserts crashes sometimes but not all of the time. But that's obviously absurd.
        cordite 11y ago
        Wondered this too, it naively only makes sense for that case with neutrinos screwing your RAM over.
        liveoneggs 11y ago
        see section 3.4 here: http://erlang.org/documentation/doc-4.9.1/doc/design_principles/sup_princ.html http://erlang.org/documentation/doc-4.9.1/doc/design_princip... "3.4 The Restart Frequency Limit Mechanism"
        geofft 11y ago
        Well, okay, so your process crashes, you restart it, it crashes a few more times, then you kill it. What's the advantage there? How does this increase availability, beyond killing it the first time it crashes? It seems actively worse to allow users to retry requests that are doomed to failure than to put up a fail-whale or similar while the ops team is being paged.
        atemerev 11y ago
        Because most production bugs are infrequent (otherwise they would be noticed by testing). They have to be logged and fixed, but not allowed to move the system into inconsistent state. Restart first, fix later.
        geofft 11y ago
        Are they? The bug discussed in this comment was extremely deterministic. There's a difference between infrequent in the sense that, across lots of users and lots of requests it happens rarely, and infrequent in the sense that, for one particular use, it only triggers sometimes. Also, the bug discussed in this article wasn't causing crashes. What would you propose be crashed and restarted in this case?
- chris_wot 11y ago
  > Bugs are common; we have to learn to work around them. Or we could, you know, fix them. I wasn't asking for a justification. I was just asking why this is occurring. If you don't know, that's cool. I mean, one of the reasons I ask is because I'd like to know if VMWare are going to fix this bug. So thank you for explaining that software has bugs. I'm sure I'll remember that the next time I fix a regression in LibreOffice, as I did with the issue with EMF dashed lines not displaying correctly or when I fixed the issue where JPEG exports didn't export the DPI value correctly...
  - mikeash 11y ago
    Just for future reference, something like "Do we know exactly what the bug in VMWare is, and whether they're going to fix it?" would be way more effective at getting the answer you're looking for here. "Uh... but why?!?" sounds like cursing at the sky, and gets a response appropriate for that.
    - chris_wot 11y ago
      Fair point.
deleted 11y ago
[deleted]

deleted 11y ago

[deleted]

pilif 11y ago

I'mm successfully running IPv6 on VMWare (Fusion, ESX 5, ESX 6) on both Clients (Debian 8, Ubuntu 12.04, FreeBSD 10.2, Windows 7, Windows 10) and Servers (Debian 8, Ubuntu 12.04, FreeBSD 10.2, Windows 2008R2) . I have not seen the issue described here in any configuration - neither on clients nor on servers. I wonder whether this is an issue with VMWare running on a specific host? edit: From the forum post in the linked article, I'm gathering they are using IPv6 NAT. So this might be a problem with the VMWare NAT interface - my configurations are all bridged.