GNOME Bugzilla – Bug 766332
data: Add a way for Rygel to be started via user systemd
Last modified: 2016-08-30 10:30:09 UTC
.
Created attachment 327715 [details] [review] data: Add a way for Rygel to be started via user systemd This will allow better tracking of whether rygel is running, ensuring that even if the manager to enable/disable its startup (gnome-settings-daemon) crashes and needs to restart, its status is still available by querying the user systemd.
*** Bug 748921 has been marked as a duplicate of this bug. ***
Does it make sense to roll out both service files, this and the system-wide together? Should the user file also be used as system file?
(In reply to Jens Georg from comment #3) > Does it make sense to roll out both service files, this and the system-wide > together? Should the user file also be used as system file? Very different use cases. The file in https://github.com/GNOME/rygel/blob/master/examples/service/systemd/rygel.service requires manual changes (at least the user name), and is built to be enabled by default on an "embedded" or single-use machine, not to run as a service under an existing session.
Review of attachment 327715 [details] [review]: ::: data/Makefile.am @@ +21,3 @@ +systemdservicedir = $(systemduserunitdir) +systemdservice_in_files = rygel.service.in +systemdservice_DATA = rygel.service This seems to break make distcheck because it tries to install to /usr/lib/systemd/user, ignoring prefix. Any suggestions?
(In reply to Jens Georg from comment #5) > Review of attachment 327715 [details] [review] [review]: > > ::: data/Makefile.am > @@ +21,3 @@ > +systemdservicedir = $(systemduserunitdir) > +systemdservice_in_files = rygel.service.in > +systemdservice_DATA = rygel.service > > This seems to break make distcheck because it tries to install to > /usr/lib/systemd/user, ignoring prefix. Any suggestions? You should add something like this to the top-level Makefile.am: DISTCHECK_CONFIGURE_FLAGS = --with-systemduserunitdir='$${libdir}/systemd/user-distcheck' The "-distcheck" bit is just to show that it's not supposed to be there. Want me to respin a patch with that? Did you get a chance to try it? If you can't test it, I'll respin a patch, check that distcheck passes and that it works as expected with the Sharing panel before committing.
Created attachment 327764 [details] [review] data: Add a way for Rygel to be started via user systemd This will allow better tracking of whether rygel is running, ensuring that even if the manager to enable/disable its startup (gnome-settings-daemon) crashes and needs to restart, its status is still available by querying the user systemd.
Review of attachment 327764 [details] [review]: Just relaying David's comment from bug 766330 that ... ::: Makefile.am @@ +13,3 @@ build-aux/git-version-gen +DISTCHECK_CONFIGURE_FLAGS = --with-systemduserunitdir='$${libdir}/systemd/user-distcheck' ... this should be AM_DISTCHECK_CONFIGURE_FLAGS.
Attachment 327764 [details] pushed as f206586 - data: Add a way for Rygel to be started via user systemd
This is missing the SystemdService=rygel.service; right now rygel.service added can only be started manually.
Created attachment 328402 [details] [review] [PATCH 1/2] data: Add missing SystemdService for DBus activation Without this, DBus could start an independent instance of rygel.
Created attachment 328403 [details] [review] [PATCH 2/2] data: Add [Install] section to rygel.service This allows running `systemctl --user enable rygel` in order to automatically launch rygel at login. The default behavior is not changed. If lingering is also enabled for the user, rygel will be started at boot; this will then share media without needing a session. Since this disregards whether GSD would have launched rygel, it is primarily useful for headless servers and avoids the wrap-dbus hack used by the example system service.
(In reply to Jan Alexander Steffens (heftig) from comment #11) > Created attachment 328402 [details] [review] [review] > [PATCH 1/2] data: Add missing SystemdService for DBus activation > > Without this, DBus could start an independent instance of rygel. With this, is it still possible to start Rygel through DBus independently of systemd?
Sure. This just prevents the situation where DBus activates rygel and systemd still reports it as inactive. If the bus was not started in systemd activation mode, DBus activates as usual.
Review of attachment 328402 [details] [review]: +1
Review of attachment 328403 [details] [review]: +1
Review of attachment 328403 [details] [review]: > This allows running `systemctl --user enable rygel` in order to > automatically launch rygel at login. I really don't like this, it would clash with gnome-settings-daemon's Sharing support. I'll start getting bugs that the 2 aren't in sync, etc. We want the default to be "rygel is not started", and for the sharing plugin of gnome-settings-daemon to be the one starting it. If we're going this way, I'm going to have to run "disable" for every one of those services when gnome-settings-daemon starts.
(In reply to Bastien Nocera from comment #17) > Review of attachment 328403 [details] [review] [review]: > > > This allows running `systemctl --user enable rygel` in order to > > automatically launch rygel at login. > > I really don't like this, it would clash with gnome-settings-daemon's > Sharing support. > > I'll start getting bugs that the 2 aren't in sync, etc. We want the default > to be "rygel is not started", and for the sharing plugin of > gnome-settings-daemon to be the one starting it. > > If we're going this way, I'm going to have to run "disable" for every one of > those services when gnome-settings-daemon starts. To my understanding, adding the first patch ensures that there will be only one for that particular user? Would gnome-settings-daemon then not know that it's already running?
You don't need to disable rygel; the default state is disabled. User interaction is required to enable it, so rygel won't launch by default. If it's enabled, the user configured it that way. Allowing rygel to be started at login/boot without the help of GSD has use outside of GNOME. Stopping rygel at GSD initialization shouldn't be any more difficult than starting it. You'll be starting and stopping rygel dynamically, anyway.
(In reply to Jan Alexander Steffens (heftig) from comment #19) > You don't need to disable rygel; the default state is disabled. User > interaction is required to enable it, so rygel won't launch by default. > > If it's enabled, the user configured it that way. Allowing rygel to be > started at login/boot without the help of GSD has use outside of GNOME. Not one that I care one iota about, and I'd rather scrap most of those patches to ship the .service files in g-s-d than to allow users to shoot themselves in the foot too easily. This has privacy concerns. > Stopping rygel at GSD initialization shouldn't be any more difficult than > starting it. You'll be starting and stopping rygel dynamically, anyway. If lingering is enabled, and the user logs out, then there's nothing to stop rygel when the network changes. This is a privacy concern.
(In reply to Bastien Nocera from comment #20) > (In reply to Jan Alexander Steffens (heftig) from comment #19) > > You don't need to disable rygel; the default state is disabled. User > > interaction is required to enable it, so rygel won't launch by default. > > > > If it's enabled, the user configured it that way. Allowing rygel to be > > started at login/boot without the help of GSD has use outside of GNOME. > > Not one that I care one iota about, I thought you'd have preferred if your NAS had rygel on it. :) I think supporting headless (where GNOME doesn't make much sense) systems of all kind is important. Then there is also other embedded system (Rygel is used on phones and cars). So I think non-gsd case is very important here.
(In reply to Zeeshan Ali (Khattak) from comment #21) > (In reply to Bastien Nocera from comment #20) > > (In reply to Jan Alexander Steffens (heftig) from comment #19) > > > You don't need to disable rygel; the default state is disabled. User > > > interaction is required to enable it, so rygel won't launch by default. > > > > > > If it's enabled, the user configured it that way. Allowing rygel to be > > > started at login/boot without the help of GSD has use outside of GNOME. > > > > Not one that I care one iota about, > > I thought you'd have preferred if your NAS had rygel on it. :) I think > supporting headless (where GNOME doesn't make much sense) systems of all > kind is important. Then there is also other embedded system (Rygel is used > on phones and cars). So I think non-gsd case is very important here. I don't care in the context of this bug. It's not like it would be complicated to replace the service file for those embedded cases. It will however be a major PITA if distributions have to patch rygel and other service files to work with GNOME.
You don't need to patch rygel. The default state is disabled.
(In reply to Jan Alexander Steffens (heftig) from comment #23) > You don't need to patch rygel. The default state is disabled. Sure, then the user enables it by hand, and the UI is busted because it will restart it on every new login, even if the network doesn't match. Is that right?
No, the UI is not busted because start/stop commands from GSD still have the effect they're supposed to have. If the user logs into GNOME, GSD can control rygel all it wants. In fact, I'd consider GSD running "disable" evil as it overrides user configuration with its own. In either case distributions won't need to patch rygel to work with GNOME, as the default state is disabled. But they will have to patch rygel if they want "enable" to work. Enabling rygel will start it at login because that's what the user commanded to happen. Why is this so much of an issue? People who are dependent on the GNOME UI don't run "systemctl --user enable rygel.service" on the terminal.
(In reply to Jan Alexander Steffens (heftig) from comment #25) > No, the UI is not busted because start/stop commands from GSD still have the > effect they're supposed to have. If the user logs into GNOME, GSD can > control rygel all it wants. > > In fact, I'd consider GSD running "disable" evil as it overrides user > configuration with its own. > > In either case distributions won't need to patch rygel to work with GNOME, > as the default state is disabled. But they will have to patch rygel if they > want "enable" to work. > > Enabling rygel will start it at login because that's what the user commanded > to happen. Why is this so much of an issue? People who are dependent on the > GNOME UI don't run "systemctl --user enable rygel.service" on the terminal. Or they do, and GNOME gets blamed for overriding it, or not overriding it depending on the mood of the reporter. Do what you want there, and I'll see what I need to do to not make this a pain for me.
(In reply to Bastien Nocera from comment #20) > If lingering is enabled, and the user logs out, then there's nothing to > stop rygel when the network changes. This is a privacy concern. This is completely independent of the enable status. If lingering is enabled and GSD does not shut down rygel when it exits, rygel will keep running whether it was "enabled" or not.