Uploaded image for project: 'OpenVZ'
  1. OpenVZ
  2. OVZ-4863

half-configured container starts

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Fix Version/s: OpenVZ-legacy
    • Component/s: Containers::Userspace
    • Security Level: Public
    • Environment:
      Operating System: All
      Platform: All

      Description

      vzctl 3.0.25 gives containers the amount of memory on the hostnode upon reboot, It also gives 'fake' swap which makes the OpenVZ VE appear to have the amount of swap on the main node.

      A workaround for the time being is downgrading to 3.0.24.

      Hi,

      You had me worried for a minute... Looks like there a sefualt in either the kernel or vzctl.

      [root@13 ~]# vzctl restart 1034
      Removing stale lock file /vz/lock/1034.lck
      Restarting container
      Stopping container ...
      Container was stopped
      Container is unmounted
      Starting container ...
      Container is mounted
      Adding IP address(es): 184.154.13.109
      Setting CPU limit: 200
      Setting CPU units: 1000
      Setting CPUs: 2
      Setting devices
      Segmentation fault

      2010-12-23T10:58:11-0500 vzeventd : Child 19264 failed with exit code 79
      2010-12-23T11:03:25-0500 vzctl : CT 1034 : Removing stale lock file /vz/lock/1034.lck
      2010-12-23T11:03:25-0500 vzctl : CT 1034 : Restarting container
      2010-12-23T11:03:25-0500 vzctl : CT 1034 : Stopping container ...
      2010-12-23T11:03:34-0500 vzctl : CT 1034 : Container was stopped
      2010-12-23T11:03:34-0500 vzctl : CT 1034 : Container is unmounted
      2010-12-23T11:03:34-0500 vzctl : CT 1034 : Starting container ...
      2010-12-23T11:03:34-0500 vzctl : CT 1034 : Container is mounted
      2010-12-23T11:03:35-0500 vzctl : CT 1034 : Adding IP address(es): 184.154.13.109
      2010-12-23T11:03:35-0500 vzctl : CT 1034 : Setting CPU limit: 200
      2010-12-23T11:03:35-0500 vzctl : CT 1034 : Setting CPU units: 1000
      2010-12-23T11:03:35-0500 vzctl : CT 1034 : Setting CPUs: 2
      2010-12-23T11:03:35-0500 vzctl : CT 1034 : Setting devices
      2010-12-23T11:04:29-0500 vzeventd : Child 2261 failed with exit code 79


      vzctl restart 1034
      Removing stale lock file /vz/lock/1034.lck
      Restarting container
      Stopping container ...
      Container was stopped
      Container is unmounted
      Starting container ...
      Container is mounted
      Adding IP address(es): *.*.*.*
      Setting CPU limit: 200
      Setting CPU units: 1000
      Setting CPUs: 2
      Setting devices
      Segmentation fault

        Activity

        Hide
        kir Kir Kolyshkin added a comment -

        fixed in git

        Show
        kir Kir Kolyshkin added a comment - fixed in git
        Hide
        kir Kir Kolyshkin added a comment -

        Unfortunately fixing this bug lead to another bug:

        dionysos ~ # vzctl restore 401
        Restoring container ...
        Starting container ...
        Container is mounted
        undump...
        Setting CPU units: 1000
        resume...
        Error: resume failed: No such file or directory
        Restoring failed:
        Error: CPT: lock fd is closed incorrectly: 1
        Container start failed
        Stopping container ...
        Container was stopped
        Container is unmounted

        When restoring, vzctl passes wait_p to the kernel (as LOCKFD) and then kernel expects it to close w/o any data coming. Since we changed this scheme kernel now complains.

        Need to figure out why this is needed by the kernel and how to fix the bug without breaking compatibility.

        Show
        kir Kir Kolyshkin added a comment - Unfortunately fixing this bug lead to another bug: dionysos ~ # vzctl restore 401 Restoring container ... Starting container ... Container is mounted undump... Setting CPU units: 1000 resume... Error: resume failed: No such file or directory Restoring failed: Error: CPT: lock fd is closed incorrectly: 1 Container start failed Stopping container ... Container was stopped Container is unmounted When restoring, vzctl passes wait_p to the kernel (as LOCKFD) and then kernel expects it to close w/o any data coming. Since we changed this scheme kernel now complains. Need to figure out why this is needed by the kernel and how to fix the bug without breaking compatibility.
        Hide
        kir Kir Kolyshkin added a comment -

        Andrey,

        Yours, as discussed with Pavel, it needs some kernel changes

        Show
        kir Kir Kolyshkin added a comment - Andrey, Yours, as discussed with Pavel, it needs some kernel changes
        Hide
        kir Kir Kolyshkin added a comment -

        vzctl restore should be fixed by the following GIT commit:
        http://git.openvz.org/?p=vzctl;a=commit;h=c4fd52f7301201cb9e439fad0e23b600e058a2ab

        Will appear in vzctl >= 3.0.26

        Show
        kir Kir Kolyshkin added a comment - vzctl restore should be fixed by the following GIT commit: http://git.openvz.org/?p=vzctl;a=commit;h=c4fd52f7301201cb9e439fad0e23b600e058a2ab Will appear in vzctl >= 3.0.26
        Hide
        sergeyb Sergey Bronnikov added a comment -

        Bug was fixed more than one year ago and there were no complains from reporter after fix. We believe bug fix helped and mark bug as closed.

        Show
        sergeyb Sergey Bronnikov added a comment - Bug was fixed more than one year ago and there were no complains from reporter after fix. We believe bug fix helped and mark bug as closed.

          People

          • Assignee:
            avagin@openvz.org Andrey Vagin
            Reporter:
            andrewm@123systems.net Andrew Moore
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: