Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
On Wed, 16.01.13 17:34, Frederic Crozat (fcro...@suse.com) wrote: Hi, on openSUSE, we found the need to sometime force --ignore-dependencies when systemctl is called (usually from other services / initscripts / tools started by initscripts and which can cause deadlock). I am pretty sure that this is really something to work-around (or even better: just fix) in the specific init scripts, rather than work-around in systemctl. Sorry, 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] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
'Twas brillig, and Frederic Crozat at 16/01/13 16:34 did gyre and gimble:
Hi,
on openSUSE, we found the need to sometime force --ignore-dependencies
when systemctl is called (usually from other services / initscripts /
tools started by initscripts and which can cause deadlock).
To handle this in a transparent manner, I'd like to introduce
SYSTEMCTL_OPTIONS environment variable, which, if set, would cause
systemctl to append its contents as if it was specified on command line.
Most common use case for this is using the --no-block and
--ignore-dependancies options. I found a need for this to prevent
deadlocks when certainly early packages (e.g. mandriva_everytime (if you
can remember back that far to your mdv days) which would do various h/w
fu (much of it outdated these days tho') and even start some services.
As this was done early in boot the starting of those services could
block in systemd - hence the need to use --no-block)
IIRC this is handled in the redhat initscripts (used also on Mageia -
dunno about suse...)
e.g. see this from /etc/init.d/functions (possibly a bit out of date and
IIRC slightly patched by me for Mageia too (the NO_BLOCK option)):
systemctl_redirect () {
local s
local prog=${1##*/}
local command=$2
local options=
case $command in
start)
s=`gprintf Starting %s (via systemctl): $prog`
;;
stop)
s=`gprintf Stopping %s (via systemctl): $prog`
;;
reload|try-reload)
s=`gprintf Reloading %s configuration (via systemctl):
$prog`
;;
restart|try-restart|condrestart)
s=`gprintf Restarting %s (via systemctl): $prog`
;;
esac
if [ -n $SYSTEMCTL_IGNORE_DEPENDENCIES ] ; then
options=$options --ignore-dependencies
fi
if [ -n $SYSTEMCTL_NO_BLOCK ] ; then
options=$options --no-block
fi
action $s /bin/systemctl $options $command $prog.service
}
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
Le mercredi 16 janvier 2013 à 16:58 +, Colin Guthrie a écrit :
'Twas brillig, and Frederic Crozat at 16/01/13 16:34 did gyre and gimble:
Hi,
on openSUSE, we found the need to sometime force --ignore-dependencies
when systemctl is called (usually from other services / initscripts /
tools started by initscripts and which can cause deadlock).
To handle this in a transparent manner, I'd like to introduce
SYSTEMCTL_OPTIONS environment variable, which, if set, would cause
systemctl to append its contents as if it was specified on command line.
Most common use case for this is using the --no-block and
--ignore-dependancies options. I found a need for this to prevent
deadlocks when certainly early packages (e.g. mandriva_everytime (if you
can remember back that far to your mdv days) which would do various h/w
fu (much of it outdated these days tho') and even start some services.
As this was done early in boot the starting of those services could
block in systemd - hence the need to use --no-block)
IIRC this is handled in the redhat initscripts (used also on Mageia -
dunno about suse...)
e.g. see this from /etc/init.d/functions (possibly a bit out of date and
IIRC slightly patched by me for Mageia too (the NO_BLOCK option)):
systemctl_redirect () {
local s
local prog=${1##*/}
local command=$2
local options=
case $command in
start)
s=`gprintf Starting %s (via systemctl): $prog`
;;
stop)
s=`gprintf Stopping %s (via systemctl): $prog`
;;
reload|try-reload)
s=`gprintf Reloading %s configuration (via systemctl):
$prog`
;;
restart|try-restart|condrestart)
s=`gprintf Restarting %s (via systemctl): $prog`
;;
esac
if [ -n $SYSTEMCTL_IGNORE_DEPENDENCIES ] ; then
options=$options --ignore-dependencies
fi
if [ -n $SYSTEMCTL_NO_BLOCK ] ; then
options=$options --no-block
Yes, we have a similar patch in /etc/rc.status on openSUSE, which is
using SYSTEMCTL_OPTIONS as variable name. So far, I haven't found a case
where --no-block was needed, only --ignore-dependencies was needed
(which is why I used a catch-all variable name, just in case
--no-block would be needed later, so we wouldn't need to release
another version of the package shipping /etc/rc.status).
But it is no longer enough because we started to migrate some
initscripts to systemd unit and our YaST tools have also learned to call
systemctl to start / stop services. And because of that, the
workaround in /etc/rc.status is no longer effective. And YaST team
doesn't handle to handle the SYSTEMCTL_OPTIONS workaround in their
generic service handling code (I can understand that).
--
Frederic Crozat fcro...@suse.com
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
'Twas brillig, and Frederic Crozat at 16/01/13 17:07 did gyre and gimble: I was planning to handle this environment variable in our tools but tools team would prefer to have it in systemctl. I guess I'll have to maintain this patch downstream in openSUSE :( It would seem to me that the tools is where it should be handled (as is done in the initscripts wrapper), but hey ho' - everyone prefers it done elsewhere. At least it's a relatively neat patch and hopefully it's need within Suse will disappear as the tools are refactored anyway? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
Le mercredi 16 janvier 2013 à 17:15 +, Colin Guthrie a écrit : 'Twas brillig, and Frederic Crozat at 16/01/13 17:07 did gyre and gimble: I was planning to handle this environment variable in our tools but tools team would prefer to have it in systemctl. I guess I'll have to maintain this patch downstream in openSUSE :( It would seem to me that the tools is where it should be handled (as is done in the initscripts wrapper), but hey ho' - everyone prefers it done elsewhere. :) At least it's a relatively neat patch and hopefully it's need within Suse will disappear as the tools are refactored anyway? No, YaST tool has already been updated to handle systemd (and they prefer to not handle workaround like this). We'll have to live with a patched systemctl. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
On Wed, Jan 16, 2013 at 6:15 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Frederic Crozat at 16/01/13 17:07 did gyre and gimble: I was planning to handle this environment variable in our tools but tools team would prefer to have it in systemctl. I guess I'll have to maintain this patch downstream in openSUSE :( It would seem to me that the tools is where it should be handled (as is done in the initscripts wrapper), but hey ho' - everyone prefers it done elsewhere. At least it's a relatively neat patch and hopefully it's need within Suse will disappear as the tools are refactored anyway? Environments are inherited, which is often a source of confusing behaviour, when tools don't expect a certain call chain. We generally try to avoid environment variables for other problems than debugging, user defaults, or system-wide settings. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
On Wed, 2013-01-16 at 17:34 +0100, Frederic Crozat wrote: Hi, on openSUSE, we found the need to sometime force --ignore-dependencies when systemctl is called (usually from other services / initscripts / tools started by initscripts and which can cause deadlock). Hm, what about having systemd detect when systemctl connections come from a pid inside a unit (as opposed to a logind cgroup), and automatically queuing the result as an idle operation? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
On Wed, 16.01.13 13:04, Colin Walters (walt...@verbum.org) wrote: On Wed, 2013-01-16 at 17:34 +0100, Frederic Crozat wrote: Hi, on openSUSE, we found the need to sometime force --ignore-dependencies when systemctl is called (usually from other services / initscripts / tools started by initscripts and which can cause deadlock). Hm, what about having systemd detect when systemctl connections come from a pid inside a unit (as opposed to a logind cgroup), and automatically queuing the result as an idle operation? Well, it's up to the clients to decide whether they want to wait until an operation is done or not. We have --no-block for that on the systemctl command line. We default to blocking, since that is usually what makes most sense, people assume they can use services after they started them. Making the blocking behaviour dependent on who is calling sounds like huge trouble. (My script works fine if i run it from a terminal, but fails terribly if i run it from a cronjob!) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
