Support for targeting `systemd --user` #1393

hmalphettes · 2015-11-23T05:18:30Z

Hi! I am looking at using fleet to manage a handful of machines with ssh access but without root access.
It might be a far shot or a misguided idea: please let me know if this is a dead-end.

If this is interesting I added 2 options to fleetd's configuration file to support that:

# fleetd.conf
units_dir=/home/vagrant/fleetunits
systemd_user=true

On archlinux, I can deploy example/hello.service but I get
AgentReconciler task failed: type=LoadUnit job=hello.service reason="unit scheduled here but not loaded" err=No such file or directory.
Some debugging shows that it comes from dbus's call to LinkUnitFiles; I have not figured out which folder it tries to link into yet.

Thanks for your attention.

hmalphettes · 2016-02-20T01:25:46Z

Hi and thanks for your attention.
I found out systemd --user was disabled in centos/redhat-7.
It turns out that this feature might be refactored heavily by the systemd developers before it goes any further:
https://bugzilla.redhat.com/show_bug.cgi?id=1198655#c3

So maybe it is too early to work on this for fleet?

If you have further insights regarding the future of systemd --user I am interested.

antrik · 2016-03-21T17:40:55Z

@hmalphettes at a guess, your fleetd.conf might be the culprit: although I haven't tried following the code in question, I have serious doubts this can possibly work with a relative directory...

Aside from that, I have no idea whether the approach is fundamentally feasible.

antrik · 2016-03-21T17:46:57Z

fleetd/fleetd.go

@@ -81,6 +81,7 @@ func main() {
 	cfgset.String("metadata", "", "List of key-value metadata to assign to the fleet machine")
 	cfgset.String("agent_ttl", agent.DefaultTTL, "TTL in seconds of fleet machine state in etcd")
 	cfgset.String("units_directory", "/run/fleet/units/", "Path to the fleet units directory")
+	cfgset.Bool("systemd_system", true, "When false use systemd --user)")


Why not the other way around? I hope it's not just me -- but this looks kinda backwards...

Agreed! Thanks for the review!
Fixed here: ade6154
and edited the issue description too.

Maybe you could just squash this into the previous commit, if it's not too much trouble?... If we all agree it's better this way around, there is no need to have the extra churn in permanent history :-)

Sure! Done.

jonboulle · 2016-03-22T12:43:31Z

It turns out that this feature might be refactored heavily by the systemd developers before it goes any further:

I actually like how simple/clean this patch is, but yeah, might be worth being a little more certain about the future of --user before committing to it. Could you ask systemd-devel upstream?

hmalphettes · 2016-03-23T02:04:29Z

@jonboulle I did ask the systemd-devel upstream on bugzilla and here is the response from Lukáš Nykrýn:

We are not even sure that --user will stay in upstream as is in the future.

https://bugzilla.redhat.com/show_bug.cgi?id=1198655#c4

I'll try some other avenues to get more info then.

@antrik I did not take the time to test with an absolute path for the units_dir... yet.

jonboulle · 2016-03-24T15:05:42Z

@hmalphettes I was actually referring to systemd-devel (or the GitHub project) - the bugzilla is just for RH, not really upstream.

hmalphettes · 2016-03-30T01:57:15Z

@jonboulle here we go: https://lists.freedesktop.org/archives/systemd-devel/2016-March/036091.html
thanks for the nudge!

jonboulle · 2016-03-30T11:52:04Z

Let's punt this until we see what they say.

lemenkov · 2016-03-30T14:16:18Z

Sorry for the noise - didn't get the subject of this thread properly :)

hmalphettes · 2016-04-14T01:57:25Z

So far 2 answers on the mailing list of downstream adopters who are interested:
https://lists.freedesktop.org/archives/systemd-devel/2016-April/036169.html
https://lists.freedesktop.org/archives/systemd-devel/2016-April/036170.html

I also went on IRC to get this idea reviewed. None of the systemd-devs pitched in. Apologies, I can't find the logs.
2 persons answered. They basically stated that systemd --user was feature complete and they were surprised I asked about it.

I'll keep waving my arms and asking questions when the opportunity shows up.
Cheers!

hmalphettes · 2016-04-14T02:17:08Z

@jonboulle I can't make it to Berlin for CoreOS Fest. But some of you will be there and Systemd's own Lennart will be too.
https://coreos.com/blog/coreos-fest-schedule.html

will it be possible to relay then question then?

kayrus · 2016-04-14T07:06:45Z

IRC log

dongsupark · 2016-04-28T12:19:45Z

+1 for this PR.
BTW functional/systemd_test.go needs to be also updated, as it doesn't build.

tixxdz · 2016-04-29T08:35:03Z

How about logind and maybe startups without user login loginctl enable-linger username ?

hectorj2f · 2016-05-09T14:39:28Z

I strongly believe that using systemd --user could offer a better response time when starting units with fleet. The reason is that fleet always runs a systemd link operation for each unit, and this operation is quite expensive, performance and scalability wise. So, if systemd knows where the units are located, there is not need for such a link operation.

dongsupark · 2016-07-07T09:26:23Z

@hmalphettes gentle ping.
I think the only thing we need to do is updating a functional test, as I mentioned. After it's done, I'd be happily merging this PR.

hmalphettes · 2016-07-07T10:40:39Z

@dongsupark thanks for the reminder and cheers to that!
I did not realise we were this close to merge it.

hmalphettes · 2016-07-08T08:35:03Z

functional/systemd_test.go

@@ -35,7 +35,7 @@ func TestSystemdUnitFlow(t *testing.T) {
 	}
 	defer os.RemoveAll(uDir)

-	mgr, err := systemd.NewSystemdUnitManager(uDir)
+	mgr, err := systemd.NewSystemdUnitManager(uDir, false)


@dongsupark Fixed functional/systemd_test.go here.
Thanks again for the reminder!

dongsupark · 2016-07-08T09:32:19Z

@hmalphettes Thanks. LGTM.
Though it's strange, semaphoreci isn't triggered automatically. Anyway I just ran the functional tests manually, and it's working.
One minor nit is that commit titles are not prefixed by subsystem names. But I'd say, that's no big deal, as this PR by itself is so simple as anyone can understand.
As a long-running PR is pain for everyone, I'd just merge this one next week, unless anyone has other opinion.
Thanks.

hmalphettes · 2016-07-09T02:54:38Z

@dongsupark OK, I'll rewrite the commit messages.

hmalphettes · 2016-07-09T03:02:07Z

@dongsupark Sorry I had missed https://github.com/coreos/fleet/blob/master/CONTRIBUTING.md#format-of-the-commit-message

Thanks again for the review.

hmalphettes · 2016-07-09T03:08:56Z

@dongsupark One thing that worries me when reading this PR: the initial description suggests a value for the units_dir that is wrong: a relative path.

May I edit the initial description and replace units_dir=./fleetunits by units_dir=/home/vagrant/fleetunits ?

The default location of the units directory for fleet is owned by root. When we use `systemd --user` we want this directory to be owned by a different user. Fixes coreos#1393

systemd offers users the ability to manage services under the user's control with a per-user systemd instance. This parameter enables fleet to target such instance of systemd. Fixes coreos#1393

dongsupark · 2016-07-11T07:53:30Z

@hmalphettes LGTM.
And sure, you can edit the initial description to replace a relative path with an absolute path.

hmalphettes · 2016-07-11T09:50:38Z

@dongsupark ok. Edited. Cheers!

Support for targeting `systemd --user`

jonboulle · 2016-07-14T10:26:02Z

systemd/manager.go

@@ -64,6 +60,13 @@ func NewSystemdUnitManager(uDir string) (*systemdUnitManager, error) {
 	return &mgr, nil
 }

+func createDbusConnection(systemdUser bool) (*dbus.Conn, error) {


The indirection of this function seems unnecessary - I'd just inline the conditional into NewSystemdUnitManager

@jonboulle

Let's get dbus connection directly inside NewSystemdUnitManager, instead of calling a separate function createDbusConnection(). Suggested by @jonboulle. See coreos#1393 (comment)

@jonboulle

Let's get dbus connection directly inside NewSystemdUnitManager, instead of calling a separate function createDbusConnection(). Suggested by @jonboulle. See coreos#1393 (comment)

hmalphettes mentioned this pull request Nov 27, 2015

systemd --user #1370

Closed

jonboulle added the needs review label Feb 10, 2016

jonboulle added this to the v0.12.0 milestone Feb 10, 2016

jonboulle added the kind/enhancement label Feb 10, 2016

jonboulle modified the milestones: v0.13.0, v0.12.0 Feb 10, 2016

hmalphettes mentioned this pull request Mar 8, 2016

Force services to be run by a specific user #1479

Closed

antrik reviewed Mar 21, 2016
View reviewed changes

hmalphettes force-pushed the systemd-user branch from b3b76da to ade6154 Compare March 22, 2016 04:22

hmalphettes force-pushed the systemd-user branch from ade6154 to 91b35a8 Compare March 23, 2016 01:55

hmalphettes changed the title ~~Support for targetting systemd --user~~ Support for targeting systemd --user Mar 30, 2016

jonboulle added the dependency/external label Mar 30, 2016

jonboulle modified the milestones: v1.0.0, v0.13.0 Mar 30, 2016

dongsupark force-pushed the master branch from 0338168 to 56b539f Compare May 23, 2016 17:57

dongsupark added the reviewed/needs rework label May 31, 2016

dongsupark force-pushed the master branch 2 times, most recently from 23d4b13 to 6fb1256 Compare July 1, 2016 11:07

dongsupark removed the needs review label Jul 7, 2016

hmalphettes force-pushed the systemd-user branch 2 times, most recently from c97499e to 711d073 Compare July 8, 2016 08:31

hmalphettes reviewed Jul 8, 2016
View reviewed changes

dongsupark added reviewed/lgtm and removed reviewed/needs rework labels Jul 8, 2016

dongsupark force-pushed the master branch 2 times, most recently from 54409ab to a1a21b8 Compare July 8, 2016 11:38

hmalphettes force-pushed the systemd-user branch from 711d073 to 18bee5e Compare July 9, 2016 02:58

hmalphettes force-pushed the systemd-user branch from 18bee5e to 7f8bc58 Compare July 9, 2016 03:14

hmalphettes added 2 commits July 11, 2016 13:44

fleetd: Add param --units_directory to customise the units directory

38d705f

The default location of the units directory for fleet is owned by root. When we use `systemd --user` we want this directory to be owned by a different user. Fixes coreos#1393

fleetd: Add param -systemd_user=true to use systemd --user

9b83262

systemd offers users the ability to manage services under the user's control with a per-user systemd instance. This parameter enables fleet to target such instance of systemd. Fixes coreos#1393

hmalphettes force-pushed the systemd-user branch from 7f8bc58 to 9b83262 Compare July 11, 2016 05:45

dongsupark merged commit 68566cf into coreos:master Jul 11, 2016

dongsupark pushed a commit that referenced this pull request Jul 11, 2016

Merge pull request #1393 from hmalphettes/systemd-user

72e1d96

Support for targeting `systemd --user`

jonboulle reviewed Jul 14, 2016
View reviewed changes

dongsupark mentioned this pull request Jul 14, 2016

systemd: get dbus connection directly in NewSystemdUnitManager #1635

Merged

dongsupark mentioned this pull request Oct 31, 2016

fleetd: allow users to turn off force flag for systemd.LinkUnitFiles() #1696

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for targeting `systemd --user` #1393

Support for targeting `systemd --user` #1393

hmalphettes commented Nov 23, 2015 •

edited

Loading

hmalphettes commented Feb 20, 2016

antrik commented Mar 21, 2016

antrik Mar 21, 2016

hmalphettes Mar 22, 2016

antrik Mar 22, 2016

hmalphettes Mar 23, 2016

jonboulle commented Mar 22, 2016

hmalphettes commented Mar 23, 2016

jonboulle commented Mar 24, 2016

hmalphettes commented Mar 30, 2016

jonboulle commented Mar 30, 2016

lemenkov commented Mar 30, 2016

hmalphettes commented Apr 14, 2016

hmalphettes commented Apr 14, 2016

kayrus commented Apr 14, 2016

dongsupark commented Apr 28, 2016

tixxdz commented Apr 29, 2016

hectorj2f commented May 9, 2016

dongsupark commented Jul 7, 2016

hmalphettes commented Jul 7, 2016

hmalphettes Jul 8, 2016

dongsupark commented Jul 8, 2016

hmalphettes commented Jul 9, 2016

hmalphettes commented Jul 9, 2016 •

edited

Loading

hmalphettes commented Jul 9, 2016

dongsupark commented Jul 11, 2016

hmalphettes commented Jul 11, 2016

jonboulle Jul 14, 2016

Support for targeting systemd --user #1393

Support for targeting systemd --user #1393

Conversation

hmalphettes commented Nov 23, 2015 • edited Loading

hmalphettes commented Feb 20, 2016

antrik commented Mar 21, 2016

antrik Mar 21, 2016

Choose a reason for hiding this comment

hmalphettes Mar 22, 2016

Choose a reason for hiding this comment

antrik Mar 22, 2016

Choose a reason for hiding this comment

hmalphettes Mar 23, 2016

Choose a reason for hiding this comment

jonboulle commented Mar 22, 2016

hmalphettes commented Mar 23, 2016

jonboulle commented Mar 24, 2016

hmalphettes commented Mar 30, 2016

jonboulle commented Mar 30, 2016

lemenkov commented Mar 30, 2016

hmalphettes commented Apr 14, 2016

hmalphettes commented Apr 14, 2016

kayrus commented Apr 14, 2016

dongsupark commented Apr 28, 2016

tixxdz commented Apr 29, 2016

hectorj2f commented May 9, 2016

dongsupark commented Jul 7, 2016

hmalphettes commented Jul 7, 2016

hmalphettes Jul 8, 2016

Choose a reason for hiding this comment

dongsupark commented Jul 8, 2016

hmalphettes commented Jul 9, 2016

hmalphettes commented Jul 9, 2016 • edited Loading

hmalphettes commented Jul 9, 2016

dongsupark commented Jul 11, 2016

hmalphettes commented Jul 11, 2016

jonboulle Jul 14, 2016

Choose a reason for hiding this comment

Support for targeting `systemd --user` #1393

Support for targeting `systemd --user` #1393

hmalphettes commented Nov 23, 2015 •

edited

Loading

hmalphettes commented Jul 9, 2016 •

edited

Loading