Re: [systemd-devel] Environment for prefdm.service
Hi,
Just to post on a more appropriate list than fedora-devel after the
topic came up there: The following are systemd-relevant parts of my
current RPM scriptlets with alternatives in mind. They should ensure
a usable display-manager.service exists under /lib if at least one
compatible display manager is installed, while leaving users' symlinks
under /etc/systemd override it as expected. (I imagine it to be more
intuitive for users to create the /etc/systemd symlink than to adjust
alternatives for these types of changes.)
And I apologise for suggesting it would be owned by systemd-units
earlier--it has been so long since I worked with alternatives that I
forgot the command creates the symlink itself and it is not packaged.
(I don't function well midday Mondays.) So systemd-units probably
should no longer own display-manager.service (at least when
prefdm.service disappears), instead leaving it as ghost files in the
DM packages, as alternatives works elsewhere.
As for the concern that /lib should not have a symlink created outside
of RPM files, I would give higher priority to preserving consistent
behavior for customised services under /etc/systemd/system--namely not
having packages touch them at all--especially considering the /lib
symlink target should never change from /etc/alternatives anyway. But
these are just my suggestions, and I will change my files as needed
when there is an official guideline written somewhere.
Thanks for all the info earlier.
David
%post
if [ $1 -eq 1 ] ; then
%{_sbindir}/alternatives --install %{_unitdir}/display-manager.service \
display-manager.service %{_unitdir}/example.service 10
/bin/systemctl daemon-reload /dev/null 21 || :
fi
%preun
if [ $1 -eq 0 ] ; then
%{_sbindir}/alternatives --remove \
display-manager.service %{_unitdir}/example.service
/bin/systemctl --no-reload disable example.service /dev/null 21
/bin/systemctl stop example.service /dev/null 21 || :
fi
%postun
/bin/systemctl daemon-reload /dev/null 21 || :
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Environment for prefdm.service
On Mon, 11.07.11 15:51, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (lenn...@poettering.net) said: Sorry if I'm missing something simple or if I have confused myself beyond all hope. I appreciate any advice on how to prepare this in a future-compatible way. My recommendation is to simply list display-manager.service in Alias= in [Install] in your unit file. Since that symlink can only point to one service we should be safe. The choice which one to start is done with this symlink and nothing else. While this is correct, the issue we'd have off the top of my head is if it's possible, in packaging, to have things automatically work such that: - installing multiple DMs gives you a predictable default - removing whatever the current default is falls back to other DMs that are currently installed If people want these problems solved one option would be to manage the display-manager.service symlink with Debian's alternative system, but in general I'd probably just ignore this, and just say the first installation wins. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Environment for prefdm.service
On Mon, Jul 11, 2011 at 22:11, Lennart Poettering lenn...@poettering.net wrote: On Mon, 11.07.11 15:51, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (lenn...@poettering.net) said: Sorry if I'm missing something simple or if I have confused myself beyond all hope. I appreciate any advice on how to prepare this in a future-compatible way. My recommendation is to simply list display-manager.service in Alias= in [Install] in your unit file. Since that symlink can only point to one service we should be safe. The choice which one to start is done with this symlink and nothing else. While this is correct, the issue we'd have off the top of my head is if it's possible, in packaging, to have things automatically work such that: - installing multiple DMs gives you a predictable default - removing whatever the current default is falls back to other DMs that are currently installed If people want these problems solved one option would be to manage the display-manager.service symlink with Debian's alternative system, but in general I'd probably just ignore this, and just say the first installation wins. Guess Bill meant: install gdm - get the link install kdm - link fails uninstall gdm - remove link - kdm installed but no link Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Environment for prefdm.service
Hi, On Mon, Jul 11, 2011 at 3:34 PM, Lennart Poettering lenn...@poettering.net wrote: It is distributed under /lib (along with its link under graphical.target.wants), implying it should not be changed. Unit files (and symlinks) in /etc/systemd/system will override those in /lib/systemd/system if the bear the same name. If a user wants to deviate from the system default, he should should place his own symlink /ect/systemd/system/display-manager.service and leave /lib untouched. Okay, this will work for me, at least on my current system. I now see it didn't come out that way, but I intended to ask about this in the context of package management when prefdm is no more (i.e., no catch-all default under /lib). I suppose it would be better for me to wait until a bigger player such as gdm takes the plunge, then I can follow suit. My recommendation is to simply list display-manager.service in Alias= in [Install] in your unit file. Since that symlink can only point to one service we should be safe. The choice which one to start is done with this symlink and nothing else. I will use this and a manual symlink in /etc for the time being. Thanks. David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Environment for prefdm.service
On Tue, 05.07.11 12:50, David Michael (fedora@gmail.com) wrote: Hi, I am attempting to integrate a desktop environment with Fedora 15, and it includes its own display manager. It seems that prefdm.service always fails to start with it, and multiple retries are logged in /var/log/audit and /var/log/messages . However, running the bare command taken from prefdm.service always seems to succeed without any trouble. If there is any useful log information from this event, I don't know where to find it. (It probably doesn't help that the prefdm script writes program output to /dev/null .) Copy /lib/systemd/system/prefdm.service to /etc/systemd/system/prefdm.service, so that you can edit it. Then, add StandardOutput=syslog to its [Service] section, and issue systemctl daemon-reload to tell systemd to reload the service file. Then, try systemctl start prefdm.service. Now all output from stdout and stderr will go to syslog, have a look there. And systemctl status prefdm.service will provide you with the exit code. Is there any obvious difference in the runtime environments that would cause this? The service fails both on boot and with `systemctl restart prefdm.service` on a root shell, but `/etc/X11/prefdm -nodaemon` works on the same shell. Well, systemd executes all services in completely cleaned up context, with no inherited environment or anything like that. That basically means that usually ther are no env vars but PATH and LANG set. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
