[opensuse-factory] Re: Systemd Service % specifiers in ExecStart
Le jeudi 25 août 2011 à 14:27 +0200, Dr. Werner Fink a écrit :
Hi,
does anyone know how systemd.service(5):
ExecStart= [...] Unless Type=forking is set, the process started via this command line will be considered the main process of the daemon. The command line accepts % specifiers as described in systemd.unit(5). On top of that basic environment variable substitution is supported, where ${FOO} is replaced by the string value of the environment variable of the same name. Also $FOO may appear as separate word on the command line in which case the variable is replaced by its value split at whitespaces. Note that the first argument (i.e. the binary to execute) may not be a variable, and must be a literal and absolute path name.
will work ... currently it does not and a
systemctl show kdm@tty7.service
will cause
[...] Type=forking Restart=no PIDFile=/var/run/kdm.pid NotifyAccess=none RestartUSec=100ms TimeoutUSec=1min 30s ExecStartPre={ path=/bin/echo ; argv[]=/bin/echo %p %P %I %n %N %f ; ignore=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/ } ExecStart={ path=/usr/bin/%p ; argv[]=/usr/bin/%p ; ignore=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/ } [...]
also a
systemctl start kdm@tty7.service
According to upstream, you are not supposed to create path "on the fly"
like this. And ExecStart is not started in a shell, so it doesn't expand
everything like a shell.
If %p and other don't work, please open a bugreport on
https://bugs.freedesktop.org/ against systemd.
--
Frederic Crozat
On Thu, Aug 25, 2011 at 02:56:37PM +0200, Frederic Crozat wrote:
According to upstream, you are not supposed to create path "on the fly" like this. And ExecStart is not started in a shell, so it doesn't expand everything like a shell.
If %p and other don't work, please open a bugreport on https://bugs.freedesktop.org/ against systemd.
Guess: it's useless or do you think that Lennard will accept anything else as his own (political) opinion :? Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have. Nevertheless this line ExecStart=/sbin/start_daemon -p /var/run/%p.pid /usr/bin/%p does work, indeed :/ Or should we use a meta template for this, that is to produce for each Display Manager its own service unit file and enable it with the graphical.target (which reqiures to remove the current active one). This indeed would require a generator script. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le jeudi 25 août 2011 à 15:07 +0200, Dr. Werner Fink a écrit :
On Thu, Aug 25, 2011 at 02:56:37PM +0200, Frederic Crozat wrote:
According to upstream, you are not supposed to create path "on the fly" like this. And ExecStart is not started in a shell, so it doesn't expand everything like a shell.
If %p and other don't work, please open a bugreport on https://bugs.freedesktop.org/ against systemd.
Guess: it's useless or do you think that Lennard will accept anything else as his own (political) opinion :?
No idea..
Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have.
Well, according to upstream, DM should have their own native .service
(and preferably not through a generator) and not a meta service to
handle them..
--
Frederic Crozat
On Thu, Aug 25, 2011 at 03:17:04PM +0200, Frederic Crozat wrote:
Le jeudi 25 août 2011 à 15:07 +0200, Dr. Werner Fink a écrit :
On Thu, Aug 25, 2011 at 02:56:37PM +0200, Frederic Crozat wrote:
According to upstream, you are not supposed to create path "on the fly" like this. And ExecStart is not started in a shell, so it doesn't expand everything like a shell.
If %p and other don't work, please open a bugreport on https://bugs.freedesktop.org/ against systemd.
Guess: it's useless or do you think that Lennard will accept anything else as his own (political) opinion :?
No idea..
Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have.
Well, according to upstream, DM should have their own native .service (and preferably not through a generator) and not a meta service to handle them..
I'd like to know what the users around here do think about this. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 2011-08-25 at 15:07 +0200, Dr. Werner Fink wrote:
Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have.
I would have thought that having just one (or at most two) display managers would be a major feature :-) is there really any good reason why we would want to invest time in supporting so many ? or is it just a feature of desktops that they like to write their own (different) DM ? gdm, kdm ... lxdm, lightdm, twmdm ? ;-) where next ? ATB, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Thu, 25 Aug 2011 20:45:46 +0100
schrieb Michael Meeks
On Thu, 2011-08-25 at 15:07 +0200, Dr. Werner Fink wrote:
Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have.
I would have thought that having just one (or at most two) display managers would be a major feature :-)
Well, at least kdm and gdm are broken all the time. kdm does not work well with anything but KDE, gdm does not work well with KDE. Additionally, gdm likes to forget that I do *not* want to log into gnome3 but xfce. gdm is better as it works at least well with xfce, but since gnome3 has happened, something is always broken, in gdm less than in gnome, but still. So I'm happy to have lxdm as fallback for the case gdm fails again on me trying to log into XFCE. xdm is a bit too spartanic for me. So there is a case for at least 3 of them besides xdm (I'm not arguing for the removal of kdm and gdm, even though this certainly would be an interesting possibility to solve the problem). And of course these are probably all old bugs, long fixed etc, but I'm still not wanting to trust my login on only gdm or kdm. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Dr. Werner Fink wrote:
Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have.
Well, you could just start a wrapper script that does the magic, like rcxdm ... OTOH that DISPLAYMANAGER variable isn't the most beautiful and scalable solution anyways. I guess we only still have it because noone bothered to request YaST to support a different method. IMO having separate init scripts (or systemd service files) for each DM would be just fine. We don't have something like rcmta or rcwebserver either after all. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le vendredi 26 août 2011 à 08:54 +0200, Ludwig Nussel a écrit :
Dr. Werner Fink wrote:
Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have.
Well, you could just start a wrapper script that does the magic, like rcxdm ... OTOH that DISPLAYMANAGER variable isn't the most beautiful and scalable solution anyways. I guess we only still have it because noone bothered to request YaST to support a different method. IMO having separate init scripts (or systemd service files) for each DM would be just fine. We don't have something like rcmta or rcwebserver either after all.
Something like display-manager.service (it is already specified in
systemd.special(7)) could be symlinked to the "wanted" display manager
service.
--
Frederic Crozat
On Fri, Aug 26, 2011 at 10:15:53AM +0200, Frederic Crozat wrote:
Le vendredi 26 août 2011 à 08:54 +0200, Ludwig Nussel a écrit :
Dr. Werner Fink wrote:
Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have.
Well, you could just start a wrapper script that does the magic, like rcxdm ... OTOH that DISPLAYMANAGER variable isn't the most beautiful and scalable solution anyways. I guess we only still have it because noone bothered to request YaST to support a different method. IMO having separate init scripts (or systemd service files) for each DM would be just fine. We don't have something like rcmta or rcwebserver either after all.
Something like display-manager.service (it is already specified in systemd.special(7)) could be symlinked to the "wanted" display manager service.
Yep this was also my idea ... the question is how to do the work done in /etc/init.d/xdm before any display manager is started Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le vendredi 26 août 2011 à 11:38 +0200, Dr. Werner Fink a écrit :
On Fri, Aug 26, 2011 at 10:15:53AM +0200, Frederic Crozat wrote:
Le vendredi 26 août 2011 à 08:54 +0200, Ludwig Nussel a écrit :
Dr. Werner Fink wrote:
Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have.
Well, you could just start a wrapper script that does the magic, like rcxdm ... OTOH that DISPLAYMANAGER variable isn't the most beautiful and scalable solution anyways. I guess we only still have it because noone bothered to request YaST to support a different method. IMO having separate init scripts (or systemd service files) for each DM would be just fine. We don't have something like rcmta or rcwebserver either after all.
Something like display-manager.service (it is already specified in systemd.special(7)) could be symlinked to the "wanted" display manager service.
Yep this was also my idea ... the question is how to do the work done in /etc/init.d/xdm before any display manager is started
First, we should list what is really needed before starting display
manager (maybe some of the stuff there is only needed for some DM and
not for other).
Second, we could use ExecPreStart and share a common script between DM.
Another option (depending on the actions needed), at least for gdm,
could be to use internal dm "init" directory (gdm has an Init directory
whose content is started before doing anything "fancy").
--
Frederic Crozat
* Frederic Crozat
Le vendredi 26 août 2011 à 11:38 +0200, Dr. Werner Fink a écrit :
On Fri, Aug 26, 2011 at 10:15:53AM +0200, Frederic Crozat wrote:
Le vendredi 26 août 2011 à 08:54 +0200, Ludwig Nussel a écrit :
Dr. Werner Fink wrote:
Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have.
Well, you could just start a wrapper script that does the magic, like rcxdm ... OTOH that DISPLAYMANAGER variable isn't the most beautiful and scalable solution anyways. I guess we only still have it because noone bothered to request YaST to support a different method. IMO having separate init scripts (or systemd service files) for each DM would be just fine. We don't have something like rcmta or rcwebserver either after all.
Something like display-manager.service (it is already specified in systemd.special(7)) could be symlinked to the "wanted" display manager service.
Yep this was also my idea ... the question is how to do the work done in /etc/init.d/xdm before any display manager is started
First, we should list what is really needed before starting display manager (maybe some of the stuff there is only needed for some DM and not for other). Second, we could use ExecPreStart and share a common script between DM.
Currently /etc/init.d/xdm is being reorganized to remove display-manager specfic initialization, see https://bugzilla.novell.com/show_bug.cgi?id=714003 The script could use some more overhaul removing obsolete and unnecessary cruft though.
Another option (depending on the actions needed), at least for gdm, could be to use internal dm "init" directory (gdm has an Init directory whose content is started before doing anything "fancy").
The idea of the current init script (as well as the DM startup, reset scripts and the session wrapper scripts) seems to be unified behavior across all supported display managers. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Aug 26, 2011 at 12:19:17PM +0200, Guido Berhoerster wrote:
Another option (depending on the actions needed), at least for gdm, could be to use internal dm "init" directory (gdm has an Init directory whose content is started before doing anything "fancy").
The idea of the current init script (as well as the DM startup, reset scripts and the session wrapper scripts) seems to be unified behavior across all supported display managers.
Exactly this was and is my intention ;) Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Dr. Werner Fink
On Fri, Aug 26, 2011 at 12:19:17PM +0200, Guido Berhoerster wrote:
Another option (depending on the actions needed), at least for gdm, could be to use internal dm "init" directory (gdm has an Init directory whose content is started before doing anything "fancy").
The idea of the current init script (as well as the DM startup, reset scripts and the session wrapper scripts) seems to be unified behavior across all supported display managers.
Exactly this was and is my intention ;)
Good, it makes sense to preserve that. Unfortunately in case of the session wrapper scripts it doesn't work out all that well in practice and there is overlap and dulication with /etc/xdg/autostart/ and DE startup scripts. I'd love to address that but that would be a different topic/bug report. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Aug 26, 2011 at 11:38:12AM +0200, Werner Fink wrote:
On Fri, Aug 26, 2011 at 10:15:53AM +0200, Frederic Crozat wrote:
Le vendredi 26 août 2011 à 08:54 +0200, Ludwig Nussel a écrit :
Dr. Werner Fink wrote:
Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have.
Well, you could just start a wrapper script that does the magic, like rcxdm ... OTOH that DISPLAYMANAGER variable isn't the most beautiful and scalable solution anyways. I guess we only still have it because noone bothered to request YaST to support a different method. IMO having separate init scripts (or systemd service files) for each DM would be just fine. We don't have something like rcmta or rcwebserver either after all.
Something like display-manager.service (it is already specified in systemd.special(7)) could be symlinked to the "wanted" display manager service.
Yep this was also my idea ... the question is how to do the work done in /etc/init.d/xdm before any display manager is started
Just updated systemd ... now I do not have a german keyboard anymore and rckbd is masked out ... Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le vendredi 26 août 2011 à 12:50 +0200, Dr. Werner Fink a écrit :
On Fri, Aug 26, 2011 at 11:38:12AM +0200, Werner Fink wrote:
On Fri, Aug 26, 2011 at 10:15:53AM +0200, Frederic Crozat wrote:
Le vendredi 26 août 2011 à 08:54 +0200, Ludwig Nussel a écrit :
Dr. Werner Fink wrote:
Paths on the fly is one of our major features and IMHO very usefull to handle 6 or more Display Managers we have.
Well, you could just start a wrapper script that does the magic, like rcxdm ... OTOH that DISPLAYMANAGER variable isn't the most beautiful and scalable solution anyways. I guess we only still have it because noone bothered to request YaST to support a different method. IMO having separate init scripts (or systemd service files) for each DM would be just fine. We don't have something like rcmta or rcwebserver either after all.
Something like display-manager.service (it is already specified in systemd.special(7)) could be symlinked to the "wanted" display manager service.
Yep this was also my idea ... the question is how to do the work done in /etc/init.d/xdm before any display manager is started
Just updated systemd ... now I do not have a german keyboard anymore and rckbd is masked out ...
/etc/init.d/kbd is masked because /lib/systemd/systemd-vconsole-setup
has been adapted to do the same work at kbd (keyboard layout, compose
key, kbd rate).
If something is missing, please open a bug report on our bugzilla,
with /etc/sysconfig/keyboard and /etc/sysconfig/console attached.
--
Frederic Crozat
participants (6)
-
Dr. Werner Fink -
Frederic Crozat -
Guido Berhoerster -
Ludwig Nussel -
Michael Meeks -
Stefan Seyfried