[systemd-devel] EnvironmentFile generated during ExecStartPre phase
Hi systemd hackers, I'm wondering when exactly EnvironmentFile is read during service start. My use case is the following: the service should be started with some environment variables defined, but the variable values are not static, but rather dynamically generated using some script. This could be solved by using EnvironmentFile=-/var/run/myservice, while this file would be generated in ExecStartPre=/usr/libexec/myservice-gen-env. I did some quick testing and it seems EnvironmentFile is read before *every* ExecStart*. Is this something I can rely on? Cheers, Honza ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] EnvironmentFile generated during ExecStartPre phase
On 10/31/2012 03:46 PM, Mantas Mikulėnas wrote: On Wed, Oct 31, 2012 at 3:28 PM, Honza Horak wrote: My use case is the following: the service should be started with some environment variables defined, but the variable values are not static, but rather dynamically generated using some script. This could be solved by using EnvironmentFile=-/var/run/myservice, while this file would be generated in ExecStartPre=/usr/libexec/myservice-gen-env. This could also be solved by using the script directly as ExecStart, and having it `exec` the real service (possibly `exec "$@"`) as its last step. That way, you wouldn't need to actually generate a file (just `export` the variables before exec'ing) or rely on specific execution order. Thanks for that idea, I was thinking about that too, but didn't like adding a new executable only for that purpose... However, thinking a bit more about it again, I like it more, since it is cleaner. So I'll probably choose this way. Honza ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] environment/configuration in socket unit files
Hi, I'm creating some systemd unit files for Fedora (currently myslq just FYI), but I need to set a socket path in the mydaemon.socket unit file according to user's configuration, which is provided by an executable. My intention is to store the generated configuration into a temporary file (/usr/lib/mydaemon/config in the following example), which has new-line separated values and thus can be used in EnvironmentFile. Is it possible to use variables like EnvironmentFile in a socket unit files somehow, e.g. like in the following example? systemd doesn't complain, but I don't know if it is legal. And what do you thing about using a temporary file for storing new-line separated values? Do you have a better solution? mydaemon.socket: [Unit] Description=MyDaemon socket [Service] EnvironmentFile=-/etc/sysconfig/network EnvironmentFile=-/etc/sysconfig/mydaemon EnvironmentFile=-/usr/lib/mydaemon/config ExecStartPre=/usr/lib/mydaemon/get-config.sh [Socket] ListenStream=/var/lib/mysql/mysql.sock [Install] WantedBy=sockets.target Thanks Regards, Honza ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] sub-processes handling question
Hi, I'm wondering how good systemd is in killing all sub-processes when a service fails/ends (un)expectedly. Let's say a service forks several times during its execution and the forked processes do some nasty work to detach from parent process. Can we be sure that all processes will be interrupted/killed after main service process ends/fails? Thanks for any reply Cheers, Honza * English - detected * Czech * English * German * Czech * English * German <#> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Service name accessible in a unit file?
Hi,
I wonder if a name of service can be accessed in service file somehow?
Let's have the following script (e.g. part of a former SysV init script):
thisname=`basename $0`
. /etc/$thisname
If I'd like to create the same behavior in systemd, e.g.:
EnvironmentFile=/etc/${thisname}
Is it possible?
It would be useful for many services to know its name, because if we
create a new service using
cp /lib/systemd/system/foo.service etc/systemd/system/bar.service,
we need to change the configuration file by hand always, which is really
easy to forget and make some problems unnecessarily.
Honza
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service name accessible in a unit file?
On 07/26/2011 09:28 AM, Honza Horak wrote:
If I'd like to create the same behavior in systemd, e.g.:
EnvironmentFile=/etc/${thisname}
Is it possible?
I found the answer myself, sorry for noise. We can get this by %p, %n,
etc., more info in
http://0pointer.de/public/systemd-man/systemd.unit.html
Honza
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] environment/configuration in socket unit files
On 08/02/2011 01:06 AM, Lennart Poettering wrote: On Tue, 19.07.11 19:27, Honza Horak (hho...@redhat.com) wrote: Hi, I'm creating some systemd unit files for Fedora (currently myslq just FYI), but I need to set a socket path in the mydaemon.socket unit file according to user's configuration, which is provided by an executable. Hm, waht's the usecase here? Why is that path configurable? mysql has a very specific way of handling configuration, there is a script which parses several files.. And user's socket path can be set differently in these files, so I just wanted to respect their settings. However, we don't ship a socket file right now, so this issue isn't actual anymore. Honza My intention is to store the generated configuration into a temporary file (/usr/lib/mydaemon/config in the following example), which has new-line separated values and thus can be used in EnvironmentFile. I can't say I like this idea, but this should work. Is it possible to use variables like EnvironmentFile in a socket unit files somehow, e.g. like in the following example? systemd doesn't complain, but I don't know if it is legal. And what do you thing about using a temporary file for storing new-line separated values? Do you have a better solution? Yes, you may use EnvironmentFile, but they only have an effect on ExecStartXX lines. You cannot resolve env vars in ListenStream= directives with that. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] ExecStartPost= behavior on failure
Hi, I'm thinking of what is the desired behavior if the command ExecStartPost=somecommand fails. If I understand it correctly, all other ExecStartPost= commands execution is stopped, but the main process continues to work (and the service is still active). From my POV this should happen when ExecStartPost= starts with '-'. But when '-' is not used, the service as well as the main process should be ended by systemd. Is the present behavior really desired? And if so, how do I make systemd to stop the service when ExecStartPost= fails? Is it possible to define this in a unit file somehow? Regards, Honza ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Creating unit file - conditional process arguments
Hi all, Let's have the following case: the environment variable $FOO can be defined but it doesn't have to be. Then I want to pass this variable to a process in the unit file like "--foo $FOO", but only if the variable is not empty. Something like the following has been done in the SysV init script: if [ "$FOO" ]; then MYARGS="--foo $FOO" fi Do I have to create the same bash script and execute it like: ExecStartPre=/path/to/simple/script ExecStart=/path/to/daemon $MYARGS or is there any better way how to do it? Thanks, Honza ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] mysqld about back to use mysqld_safe in Fedora
Hi guys, we've met some problems around mysqld and systemd's auto-restart feature recently in Fedora, which has been fortunately fixed by Michal few days ago [1]. However, there are still some doubts, which convince us to go back and use mysqld_safe script for monitoring and restarting potential crashed main process, instead of let it be done by systemd. One of the issue is (in)ability to imitate the original behavior of mysqld_safe, which restarts the main process only if it crashes and the pid file isn't properly cleaned up. There's probably not a way how to do something like that in systemd, is it? AFAIK we can only use option on-abort, but we'd have to be sure that exit code is never 0 in cases we want the daemon to be restarted. Another issue is the PID file guessing. It usually works fine, but if we want to be sure what pid is monitored, we should use PIDFile= option. However, when we use this we don't know when the pidfile is created, while waiting some sane time is not a nice solution and could bring another issues. Using notify feature doesn't helps us, since we used Type=forking. Another problem is, that since the main process pid is known too late, we cannot use it in mysqld-wait-ready, which is a script run in ExecStartPost to check if mysqld daemon is ready to accept connections. There have been another thoughts like socket activation when we were working on mysqld unit file a year ago, but this feature seemed to be more problematic than helpful. Feel free to go through the discussion to read more at [2]. As written above, we're about to use mysqld_safe to do all the stuff around monitoring the main process and changing service to Type=simple again. Maybe you're asking why I'm telling you. Well, take it as a feedback, what issues we currently have during mysqld packaging. And off course, if you have any thoughts that can help, we'll be happy to hear that. [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=0c7f15b3a95c3596a4756de5c44eb1fdcd0034fc [2] https://bugzilla.redhat.com/show_bug.cgi?id=714426 Cheers, Honza ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mysqld about back to use mysqld_safe in Fedora
On 06/27/2012 02:50 PM, Honza Horak wrote: Another issue is the PID file guessing. It usually works fine, but if we want to be sure what pid is monitored, we should use PIDFile= option. However, when we use this we don't know when the pidfile is created, while waiting some sane time is not a nice solution and could bring another issues. Using notify feature doesn't helps us, since we used Type=forking. Thinking a bit about this issue, it would be good if systemd had something like WaitForPidFile=true option and didn't leave ExecStart= section in this case until the pid file (specified by PIDFile=) would be created. Using this we could possibly get rid of scripts like mysqld-wait-ready, which simply wait for service to be ready. Thoughts? Honza ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mysqld about back to use mysqld_safe in Fedora
On 06/27/2012 07:01 PM, Lennart Poettering wrote:
Hmm, well, not really. "on-abort" means that systemd would only restart
the service on actual crashes, i.e. where the main process exits with a
signal like SIGSEGV, SIGBUS or SIGABRT. This is different from
"on-failure" which is the behaviour you describe where we'd also restart
the service if it exists with a non-zero exit code.
I am pretty sure "on-abort" is actually what you really want here, no?
The PID file checking sounds like a hack to achieve the same?
Not really, there are cases where mysqld notices fatal problems, gives
up and crashes without a signal with exit-code 1. In this case we want
still to restart it. On the other hand there are cases where mysqld
cleans up and still returns 1. In this case we don't want to restart it
(wrong configuration is one example). I don't see this as the best
design, but changing it would be too painful. Since we'd like to
preserve current/upstream's behavior, it seems better to let the whole
auto-restarting thing to mysqld_safe script.
An alternative, more modern way to handle all this is by simply using
Type=notify and invoking sd_notify("READY=1"); in the daemon when
everything is done. This should normally be a two line patch and makes
PID files entirely redundant.
sd_notify seems to work fine, though a SELinux rule would have to be
added. I'll prepare a patch and try to offer it to upstream, but as Tom
said, we shouldn't expect much interest.
Honza
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
