Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Vagrant base box should use systemd init system (or we should stop depending on systemd) #5

Closed
paulproteus opened this issue Feb 25, 2015 · 5 comments
Closed

Vagrant base box should use systemd init system (or we should stop depending on systemd) #5

paulproteus opened this issue Feb 25, 2015 · 5 comments
Milestone
future

Comments

@paulproteus
Copy link
Collaborator

Right now, the Vagrant base box uses sysvinit, but the vagrant provision process involves adding a systemd service.

This results in sadness, since we can't really enable the service until after a reboot causes systemd to take over as PID 1.

One workaround would be to convert the systemd service into an init script. I am -0 on that, and +1 on finding a systemd-enabled Vagrant base box.
@paulproteus paulproteus added this to the future milestone Mar 9, 2015
paulproteus added a commit that referenced this issue May 5, 2015
@paulproteus
Add test for post-recovery update
0507bee 
This includes:

* A client cert keypair #5, for use with the recoveryToken to
  verify that old recoveryTokens can't be re-used.

* Fixes to the underlying recovery, where we were attempting to
  update a property on a MongoDB object that was not originally
  set, resulting in never actually setting a new key on the
  userRegistration object.
@silopolis
Copy link

May I suggest using https://github.com/boxcutter/debian base box ?!

@zarvox
Copy link
Collaborator

zarvox commented Jun 2, 2015

https://atlas.hashicorp.com/debian/boxes/jessie64/ appears to be an official effort, and uses systemd. I'd encourage us to switch to that, and I hope to do the same for vagrant-spk once I've done some testing.

@paulproteus
Copy link
Collaborator Author

paulproteus commented Jun 9, 2015 via email

@zarvox
Copy link
Collaborator

zarvox commented Jun 9, 2015

We can't currently use the systemd units to start MySQL within the Sandstorm grain. But we also can't currently use the sysvinit scripts, nor upstart jobs either.

What we do today is manually invoke mysqld from your grain's entrypoint (often a bash script). That will continue to work, but is not very declarative/reusable. So this is not a functional regression, just a future opportunity.

It would be cool if someday we could punt service bringup/supervision within the grains to systemd --user or something like that. From talking with some friends, I'm under the impression that systemd does not play nicely inside user namespaces (which we require), without /proc, or some other things that we do to our sandbox, but perhaps that situation will get better over time, or we can run systemd in some feature-limited mode or something.

@paulproteus
Copy link
Collaborator Author

paulproteus commented Jun 9, 2015 via email

@zarvox zarvox mentioned this issue Jun 12, 2015
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
future
Development

No branches or pull requests
3 participants
@paulproteus @zarvox @silopolis