Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
S
slapos.core
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 0
    • Issues 0
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 17
    • Merge Requests 17
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • nexedi
  • slapos.core
  • Merge Requests
  • !11

Open
Opened Jan 10, 2017 by Nicolas Wavrant@Nicolas
  • Report abuse
Report abuse

WIP: SlapObject: when destroying a partition, no residues from user activity should remain

When users connect to a slappart by ssh, they can run or plan tasks running in the background. As these aren't run by supervisord, they are not stopped when the slappart is destroyed, and they remain even when the slappart is attributed to another user.

In the consequence of this, instanciation errors can appear later if the services run in background are using some ports that the new user wants also to use, or even worst.

This patch proposes to kill all the processes belonging to the slapuser when its slappart is destroyed, and clean the user's crontabs and at jobs.

Check out, review, and merge locally

Step 1. Fetch and check out the branch for this merge request

git fetch https://lab.nexedi.com/Nicolas/slapos.core.git slapgrid-process-management
git checkout -b Nicolas/slapos.core-slapgrid-process-management FETCH_HEAD

Step 2. Review the changes locally

Step 3. Merge the branch and fix any conflicts that come up

git fetch origin
git checkout origin/master
git merge --no-ff Nicolas/slapos.core-slapgrid-process-management

Step 4. Push the result of the merge to GitLab

git push origin master

Note that pushing to GitLab requires write access to this repository.

Tip: You can also checkout merge requests locally by following these guidelines.

  • Discussion 6
  • Commits 2
  • Changes 1
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
0
Labels
None
Assign labels
  • View project labels
Reference: nexedi/slapos.core!11
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7