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.

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

pid1: accept single transaction to operate multiple units #8102

Open
johnlinp opened this issue Feb 5, 2018 · 1 comment

Comments

@johnlinp
Copy link
Contributor

commented Feb 5, 2018

Submission type

  • Request for enhancement (RFE)

systemd version the issue has been seen with

tested on v235, but all versions should have the same behavior

Used distribution

Arch Linux

In case of bug report: Expected behaviour you didn't see

systemctl first.service second.service should have the same behavior as systemctl second.service first.service.

In case of bug report: Unexpected behaviour you saw

The behaviors are different.

In case of bug report: Steps to reproduce the problem

  1. Create 2 service unist: first.service and second.service and configured After=first.service in second.service. Both services are Type=oneshot.
  2. Execute systemctl start first.service second.service. The ordering dependency will work, i.e. second.service will start after first.service.
  3. Execute systemctl start second.service first.service. first.service and second.service will start at the same time.

This is because systemctl doesn't operate those units in a single transaction since there are no such API provided by pid1.

It's from the mailing list: https://lists.freedesktop.org/archives/systemd-devel/2018-January/040122.html.

Werkov added a commit to Werkov/systemd that referenced this issue Feb 14, 2018

WIP: draft API for mutliple anchor jobs in transaction
Draft, does not compile, will be (force) pushed over

Ref: systemd#8102

Werkov added a commit to Werkov/systemd that referenced this issue May 21, 2018

WIP: draft API for mutliple anchor jobs in transaction
Draft, does not compile, will be (force) pushed over

Ref: systemd#8102

Werkov added a commit to Werkov/systemd that referenced this issue Nov 23, 2018

WIP: draft API for mutliple anchor jobs in transaction
Draft, does not compile, will be (force) pushed over

Ref: systemd#8102
@Werkov

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2018

Some ideas that came to my mind:

  1. Create a temporary (internal) target that would aggregate all the units passed through systemctl CLI
  • unclear management of that unit
  • works for systemctl only, not DBus API
  1. Allow "vectorized" operations
  • DBus API methods like StartUnit -> StartUnits
  • transaction engine ensures the jobs are created within the same transaction
  1. Allow aggregating multiple jobs
  • DBus API methods like BeginJobsGroup, EndJobsGroup and insert operations between those
  • stateful communication, could be abused to DOS (PID would need limits of on groups in flight)

What are you opinions? Are there any other approaches?

I'm pursuing number 2) in single-tx-jobs but I'd like to hear some opinion before touching the DBus API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.