g-t-s is dbus activated, which requires a service file to work, so it already has one:

$ cat /usr/share/dbus-1/services/org.gnome.Terminal.service 
[D-BUS Service]
Name=org.gnome.Terminal
Exec=/usr/libexec/gnome-terminal-server

I was talking here about a _systemd_ .service file

*** Bug 759633 has been marked as a duplicate of this bug. ***

Got a patch?

Dupe of bug 744736?

No.

This is related to the thread that prompted #744736, though: as noted in that thread (<https://lists.freedesktop.org/archives/dbus/2015-February/016540.html>), if #744736 isn't implemented first, the systemd user service would need to have KillMode=main.

I might implement this just so that my terminal-based processes stop showing up in dbus.service :-)

Created attachment 325824 [details] [review]
Add a systemd user service file for gnome-terminal-server

With this service file, the processes started using gnome-terminal will
not be classified in the same cgroup as dbus.

Created attachment 325825 [details] [review]
Add a systemd user service for the terminal server

This is used to implement the D-Bus session service if
"dbus-daemon --session" was configured to use systemd activation,
most commonly via the units installed by configuring dbus 1.10+
with --enable-user-session.

With this service, child processes such as the user's shell
end up in the cgroup .../user@UID.service/org.gnome.Terminal.service
instead of in .../user@UID.service/dbus.service.

---

Sorry, I must have written this about the same time Laurent did... I think this one is maybe a little better so I'm attaching it anyway.

This is the simple version with no switchable path or optional installation of systemd services. Some maintainers prefer this, some prefer to have the configure option. I personally don't think the configure option is particularly useful, so I'm going to attach it separately.

Created attachment 325826 [details] [review]
Make systemd user unit presence and location configurable

---

Optional add-on for Attachment #325825 [details] to add --with-systemduserunitdir=PATH and --without-systemduserunitdir. I personally don't think these are amazingly useful - installing one extra text file on non-Linux is hardly a huge burden - but some maintainers strongly prefer to have them, so apply this if desired or ignore it if not.

Review of attachment 325824 [details] [review]:

::: configure.ac
@@ +156,3 @@
+  [systemduserservicedir="$withval"],
+  [systemduserservicedir='${prefix}/lib/systemd/user'])
+AC_SUBST([systemduserservicedir])

The conventional name seems to be `--with-systemduserunitdir`. I don't particularly like that name (I'd add at least a couple of extra `-` if it was my idea) but having it similar between packages seems valuable.

I don't think adding this option but not supporting `--without-systemduserunitdir` (exactly equivalent to `--with-systemduserunitdir=no`) is a good idea: if we're going to have the option at all, we might as well have both of its meanings (again, uniformity between packages).

::: src/Makefile.am
@@ +17,2 @@
 dbusservice_DATA = org.gnome.Terminal.service
+systemduserservice_DATA = gnome-terminal-server.service

I've been using a convention that the systemd service is named the same as the .desktop file, where there is one, on the basis that at one point there was some talk of having a user-unit generator taking /etc/xdg/autostart as input, which would provide/rely on that convention.

This name seems fine if the maintainer would prefer it though.

@@ +143,3 @@
 		      echo "Name=org.gnome.Terminal"; \
+		      echo "Exec=${libexecdir}/gnome-terminal-server";
+		      echo "SystemdService=gnome-terminal-server.service") > $@

This last line should not be added (or should be commented out) if the systemd service is disabled with `--without-systemduserunitdir`, because otherwise, activation would fail (if a user explicitly disables systemd integration, but later switches to systemd anyway).

@@ +148,3 @@
+	$(AM_V_GEN) ( echo "[Unit]"; \
+		      echo "Description=GNOME Terminal Emulator"; \
+		      echo "Documentation=man:gnome-terminal(1)"; \

The man page appears to be Debian-specific, so I wouldn't tend to add this unless the man page goes upstream.

Wouldn't it be better if the systemd .service file was called gnome-terminal-server.service instead of org.gnome.Terminal.service?

Looking in the debian packages, I don't see any .service named after the bus name (gvfs for examples are named after the executable name)

(In reply to Laurent Bigonville from comment #12)
> Wouldn't it be better if the systemd .service file was called
> gnome-terminal-server.service instead of org.gnome.Terminal.service?

As I said, I was basing this on the .desktop filename, since there is one.

I wouldn't mind changing this, though, even if "systemd service = desktop file" turns out to be a convention that's followed in future: getting the name right first time is less important for systemd services, because unlike desktop files, symlinks-as-aliases are understood by systemd.

Created attachment 325839 [details] [review]
Add a systemd user service for the terminal server

This is used to implement the D-Bus session service if
"dbus-daemon --session" was configured to use systemd activation,
most commonly via the units installed by configuring dbus 1.10+
with --enable-user-session.

With this service, child processes such as the user's shell
end up in the cgroup .../user@UID.service/org.gnome.Terminal.service
instead of in .../user@UID.service/dbus.service.

---

Altered to use gnome-terminal-server.service for the systemd service.

Created attachment 325840 [details] [review]
Make systemd user unit presence and location configurable

Installing metadata for "systemd --user" even on systems where it is
not used is very low-overhead (one small text file), but in projects
where it is made optional, the configure option is conventionally
--without-systemduserunitdir.

The same configure option also controls where the user units are to be
installed, if not disabled. In practice systemd is very likely to be
installed in /usr, so the default is correct for --prefix=/usr, and
other prefixes will require linking, copying or moving the units
into the systemd search path.

---

Longer commit message; use gnome-terminal-server.service

I committed the first patch, but I don't see any need to make the location configurable, so unless a strong argument for that appears, I'll pass up on the 2nd patch.

This should take care of the common case of the g-t-server being started from dbus. But when the user (or some ******* distro scripts) start g-t-server with --app-id manually, all the child processes will still end up in the wrong cgroup, wont' they? Anything we can do about that?

(In reply to Christian Persch from comment #16)
> I committed the first patch, but I don't see any need to make the location
> configurable, so unless a strong argument for that appears, I'll pass up on
> the 2nd patch.

Sounds good to me. Some maintainers seem to feel really strongly that the location or install-or-not or both must be configurable, so I provided the second patch to avoid having to do another review round-trip if you rejected the simpler version. I slightly prefer not applying it - much simpler!

> This should take care of the common case of the g-t-server being started
> from dbus. But when the user (or some ******* distro scripts) start
> g-t-server with --app-id manually, all the child processes will still end up
> in the wrong cgroup, wont' they? Anything we can do about that?

Yeah, if you start g-t-server manually, it runs in whatever context you ran it in, just the same as if you run "sudo dbus-daemon --system" it won't be nicely wrapped in dbus.service. I don't think we can (or should) do anything about that.

I'm curious which distro scripts do this, and why?

If a user or distribution wants a gnome-terminal-except-not for whatever reason, they could provide their own suspiciously similar systemd unit for it, I suppose...

(In reply to Simon McVittie from comment #17)
> I'm curious which distro scripts do this, and why?

It's Ubuntu, of course. You'll have to ask them for the reason.

Cherry-picked to 3-20 too.

Even with this fix this IMHO is still looks somewhat unsatisfactory, or at least weird: gnome-terminal itself and all of its children that you run in terminals are still attached to the per-user systemd instance directly, as processes that span all user sessions. But unlike "real" user services like gvfs, things run in a terminal should IMHO *not* span all sessions but be specific to the logind session that you start them under.

I. e. systemd-cgls now looks like that (shortened to only show the interesting parts):

Control group /:
└─user.slice
  └─user-1000.slice
    ├─user@1000.service
    │ ├─dbus.service
    │ │ ├─2199 /usr/bin/dbus-daemon --session --address=systemd: --nofork --n...
    │ │ ├─2462 /usr/lib/x86_64-linux-gnu/gconf/gconfd-2
    │ │ └─3116 /usr/bin/gnome-screensaver --no-daemon
    │ ├─init.scope
    │ │ ├─2139 /lib/systemd/systemd --user
    │ └─gnome-terminal-server.service
    │   ├─2394 /usr/lib/gnome-terminal/gnome-terminal-server
    │   ├─2415 bash
    │   └─3607 systemd-cgls
    └─session-c2.scope
      ├─1120 lightdm --session-child 12 19
      ├─2191 i3
      ├─2322 /usr/lib/firefox/firefox

I. e. processes started in a terminal (bash and systemd-cgls here) are detached from the logind session scope which has (and is supposed to) have all my other session processes such as firefox or the window manager (i3).

This might just be me not fully appreciating the idea of the D-Bus user session yet, but this looks highly inconsistent to me?

CC'ing Lennart in case he has some input on this, as the D-Bus user session was discussed at length on a previous systemd hackfest.

I guess that's bug 744736 ?

Somewhat related, yes. I'll follow up there, to keep the conversation on an open bug.