[systemd-devel] Question about ExecStartPost= and startup process

[Francis Moreau]

Hello,

For services with Type=Forking, I'm wondering if systemd  proceeds
starting follow-up units when the command described by ExecStart= exits
or when the one described by ExecStartPost= exits ?

I tried to read the source code to figure this out and it *seems* that
the latter is true but I'm really not sure.

What about for services with other type (simple, oneshot) ?

Also the documentation says that only one command can be given to
ExecStart if the type of the service is Forking. However I don't see
this when reading the code:

service_sigchld_event() {
...
} else if (s->control_pid == pid) {

...
if (s->control_command &&
s->control_command->command_next &&
f == SERVICE_SUCCESS) {
service_run_next_control(s);
}

In my understand this code is specific to service with Type=Forking

Could anybody clarfify ?

Thanks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about ExecStartPost= and startup process

[Reindl Harald]

Am 28.06.2015 um 12:00 schrieb Francis Moreau:

Hello,

For services with Type=Forking, I'm wondering if systemd  proceeds
starting follow-up units when the command described by ExecStart= exits
or when the one described by ExecStartPost= exits ?

I tried to read the source code to figure this out and it *seems* that
the latter is true but I'm really not sure.


after ExecStartPost because anything else would make no sense, a unit is 
started when *all* if is st started - see the recent mariadb units on 
Fedora - if systemd would fire up deaemons which depend on mariadb the 
whole "wait-ready"-stuff won't work




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why we need to read/save random seed?

[cee1]

2015-06-15 0:43 GMT+08:00 Greg KH :
> On Sun, Jun 14, 2015 at 12:49:55PM -0300, Cristian Rodríguez wrote:
>>
>> El jun. 14, 2015 10:21, "cee1"  escribió:
>> >
>> > Hi all,
>> >
>> > Why we need to read/save random seed? Can it be read from /dev/random each
>> time?
>>
>> Because the kernel is borked and still is needs to be fed of entropy at 
>> system
>> startup by user space. Please read the random man page.
>>
>> I agree we shouldn't have to do this at all..
>
> Really?  And how do you suggest we "fix" the kernel when the hardware
> itself doesn't provide us with a proper random number "seed" in the
> first place?  What do you suggest we do instead?

It seems in 4.2, kernel will use the Jitter Entropy Random Number
Generator to seed other random number generator(s):
http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-Crypto-Akcipher-PKE

And from https://www.kernel.org/doc/ols/2014/ols2014-mueller.pdf, p24:
"""
The random number generator shall not require a seeding with data from
previous instances of the random number generator.
"""

That means we can get rid off systemd-random-seed.service, starting from 4.2.



-- 
Regards,

- cee1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SysVInit service migration to systemd

[Jonathan de Boyne Pollard]

Lesley Kimmel:
I've been working with RHEL5/6 for the past several years and have 
developed many init scripts/services which generally use lock files 
and PID files to allow for tracking of the service status. We are 
moving to RHEL7 (systemd) in the near future and I am looking for 
instruction or tutorials on how to effectively migrate these scripts 
to work with systemd.   [...] It looks like I may be able to use the 
'forking' type with the 'pidfile' parameter to somewhat mimic what the 
scripts to today.


You don't do such migration.  You understand how your daemons are 
started, and you write service (and other) units to describe that. You 
do not start with the assumption that you migrate straight from one to 
the other, particularly if your existing mechanisms involve the 
dangerous and rickety things (e.g. PID files) that proper service 
management is designed to avoid in the first place, or things such as 
"subsystem" lock files which proper service management has no need of by 
its very nature.  "Type=forking" specifies a quite specific readiness 
protocol that your daemon has to enact, lest it be regarded as failed.  
It's isn't a catch-all for anything that might fork in any possible 
way.  And service managers know, by dint of simply remembering, what 
processes they started and whether they've already started them.


I've been collecting case studies of people who have migrated to systemd 
exceedingly badly, and constructed some quite horrendous systems, 
because they've done so without either consideration of, or 
understanding of, how their sytems actually work.  Here's one candidate 
that I have yet to add, because I'm hoping that now they've been told 
that they are going wrong they will correct themselves, whose errors are 
good to learn from.


There's a computer game called "ARK: Survival Evolved".  It's daemon is 
a program named ShooterGameServer.  To run this program continually as a 
daemon, someone named Federico Zivolo and a couple of other unidentified 
people came up with the somewhat bizarre idea of running it under 
screen, and using screen's commands to send its pseudo-terminal an 
interrupt character, in order to send a SIGINT to the daemon when it 
came time to shut it down.  They wrapped this up in a System 5 rc 
script, taking the conventional "start" and "stop" verbs, named 
"arkmanager".  Its prevent-multiple-instances system was not lock files, 
but grepping the process table.


Wrapped around this they put another System 5 rc script, named 
"arkdaemon", which also took the conventional "start" and "stop" verbs, 
and which treated the wrapper "arkmanager" script as the daemon, 
recording the process ID of the shell interpreter for the "arkmanager" 
script in a PID file, as if it were the actual daemon's process ID.  It 
also did various other bad things that proper service managers 
eliminate, including grepping the process table (again), abusing su to 
drop privileges, using arbitrary 5 second sleeps to make the timing 
almost work, and (sic) hardwired ECMA-48 SGR sequences to change the 
colour of output that isn't going to a terminal in the first place.


Then they wrote a systemd service unit file, "arkdeamon.service" (sic), 
that did this:


> ExecStart=/etc/init.d/arkdaemon start
> ExecStop=/etc/init.d/arkdaemon stop
> Type=forking

A couple of days ago, I pointed out the errors of even starting down 
this route to them, and wrote a systemd unit file for them that actually 
starts the daemon directly from systemd; no PID files, abuses of su, 
racy grepping of the process table, abritrary sleeps, or incorrect 
"forking" readiness protocol necessary.  Set the account with User= ; 
set the environment with Environment= ; and run the program with 
ExecStart=/home/steam/ARK/ShooterGame/Binaries/Linux/ShooterGameServer 
plus some options.  Other stuff, like software upgrades, one then builds 
on top of the service management layer, not beneath it.  I also pointed 
out to them that I had been beaten in this regard by some 4 days by the 
(again unfortunately unidentified) people who wrote 
http://ark.gamepedia.com/Dedicated_Server_Setup#Automatic_Startup , 
whose service unit was pretty much the same as the one that I had 
independently written (as one would expect, indeed).


If you understand how your daemon is run in the first place, then you 
end up with what I and the gamepedia people did.  If you just think that 
you wrap what you already have, using "forking" to imperfectly paper 
over the cracks, you oftentimes end up with an utterly horrendous mess.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] xinetd REMOTE_IP (feature request)

[Jonathan de Boyne Pollard]

Fisher, Charles J.:


The xinetd server from previous versions of RedHat defined a REMOTE_IP 
environment variable.


Lennart Poettering:

I wonder though whether it wouldn't be nicer to follow the variable naming used 
by CGI here, and introduce $REMOTE_ADDR and $REMOTE_PORT instead of $REMOTE_IP.


Or you could implement an existing more comprehensive protocol, of long 
standing (coming up to 20 years) in the world of spawning TCP services 
on Unix and already implemented almost a decade ago in GNU inetd (and by 
some other inetds a few years later) and available right now in inetd on 
systems like Ubuntu 14 LTS:


* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/UCSPI.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] scope vs service units

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey. I would like to ask about service vs scope units, both can be
created programmatically, so what is a difference/usage scenario for
programmatically created service vs scope units if service would have
type simple?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVkCXdAAoJEHb1CzgxXKwYl38P/j4BBdaXGVvMO7FeT+bb1vuu
KqSmnsIzmS9YpHRNT3XUvcAUxDSqax54AZ7446/5+sK09yruI8WqfMySaq9Izyde
ZduTUewBOvYgj9mcpbKbIDN8D24W3X3fD6N9NXM+iMF2iwFZoEhpB4lwBUQ3qKTb
ec0ZmjtLRP/34wJWtKxZ9L0rVmVpfRb9HEHz9/vTpi92wck12oE5iEnJruh0y7UQ
Yzho23ErPhYOVpbOgFHXjJCPjBR3+BETN2E8uTrjlgFFi7Fp5DoOwuyzZ+iTJCx+
e7e4tY4NPqlQUx9imMrdNZFZpxsKSELZrBCHGKU2E+dlR+ILyI8d3qT9mAtZzfNY
KP1gqiuj3V9rNTbEEHb9FqP8aDbIyPgzLvszPFd0ZBKA5El05DjFZ7PcX1+cg7DW
h3DJYxzu7BxuXXqu1vEIgz58+5pkDRtSoUb3S+RsVCOQjDcAOPKL1pm6WD/kIkXa
dQHBiqcaGOkz4iUBarIELLJcJx8OYrDsMjb+JK2rN8lw40aqoZbwURL2sMU5lVvI
I3BE85zknKmZaOGAohz2tB7f4ffnu3niGgJ00t2xbw9y8FrLcxwEzGP3HI8KqQa8
nNffGN809vdxsgr7Hpj2db8SLHxP4V7L2js2UmrZ0XnHpG33Rapkh9G8EUWcRneW
kQY6rsdHJeydn9NkQoXa
=lwua
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about ExecStartPost= and startup process

[Francis Moreau]

On 06/28/2015 01:01 PM, Reindl Harald wrote:
> 
> 
> Am 28.06.2015 um 12:00 schrieb Francis Moreau:
>> Hello,
>>
>> For services with Type=Forking, I'm wondering if systemd  proceeds
>> starting follow-up units when the command described by ExecStart= exits
>> or when the one described by ExecStartPost= exits ?
>>
>> I tried to read the source code to figure this out and it *seems* that
>> the latter is true but I'm really not sure.
> 
> after ExecStartPost because anything else would make no sense, a unit is 
> started when *all* if is st started - see the recent mariadb units on 
> Fedora - if systemd would fire up deaemons which depend on mariadb the 
> whole "wait-ready"-stuff won't work
> 

Ok, then the next naive question would be: "then what the purpose of the
ExecStartPost= directive since several commands can already be 'queued'
with the ExecStart= one ?

Thanks.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] util: fix incorrect escape sequence in string_is_safe()

[Eric Biggers]

---
 src/basic/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/basic/util.c b/src/basic/util.c
index 727be56..906e4ab 100644
--- a/src/basic/util.c
+++ b/src/basic/util.c
@@ -3627,7 +3627,7 @@ bool string_is_safe(const char *p) {
 if (*t > 0 && *t < ' ')
 return false;
 
-if (strchr("\\\"\'\0x7f", *t))
+if (strchr("\\\"\'\x7f", *t))
 return false;
 }
 
-- 
2.1.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about ExecStartPost= and startup process

[Andrei Borzenkov]

В Sun, 28 Jun 2015 19:02:57 +0200
Francis Moreau  пишет:

> On 06/28/2015 01:01 PM, Reindl Harald wrote:
> > 
> > 
> > Am 28.06.2015 um 12:00 schrieb Francis Moreau:
> >> Hello,
> >>
> >> For services with Type=Forking, I'm wondering if systemd  proceeds
> >> starting follow-up units when the command described by ExecStart= exits
> >> or when the one described by ExecStartPost= exits ?
> >>
> >> I tried to read the source code to figure this out and it *seems* that
> >> the latter is true but I'm really not sure.
> > 
> > after ExecStartPost because anything else would make no sense, a unit is 
> > started when *all* if is st started - see the recent mariadb units on 
> > Fedora - if systemd would fire up deaemons which depend on mariadb the 
> > whole "wait-ready"-stuff won't work
> > 
> 
> Ok, then the next naive question would be: "then what the purpose of the
> ExecStartPost= directive since several commands can already be 'queued'
> with the ExecStart= one ?
> 

Long running services (i.e. daemons) are represented by systemd with
PID of main process (which is *the* service for systemd). With multiple
ExecStart commands there is no obvious way to know which of started
processes is the main one. That's the reason to allow just one command
there. Once main process is known, it is possible to have any number of
followup ExecStartPost commands.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] util: fix incorrect escape sequence in string_is_safe()

[systemd github import bot]

Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about ExecStartPost= and startup process

[Reindl Harald]

Am 28.06.2015 um 19:02 schrieb Francis Moreau:

On 06/28/2015 01:01 PM, Reindl Harald wrote:


Am 28.06.2015 um 12:00 schrieb Francis Moreau:

Hello,

For services with Type=Forking, I'm wondering if systemd  proceeds
starting follow-up units when the command described by ExecStart= exits
or when the one described by ExecStartPost= exits ?

I tried to read the source code to figure this out and it *seems* that
the latter is true but I'm really not sure.


after ExecStartPost because anything else would make no sense, a unit is
started when *all* if is st started - see the recent mariadb units on
Fedora - if systemd would fire up deaemons which depend on mariadb the
whole "wait-ready"-stuff won't work


Ok, then the next naive question would be: "then what the purpose of the
ExecStartPost= directive since several commands can already be 'queued'
with the ExecStart= one?


no, they can't, not for every service type
"When Type is not oneshot, only one command may and must be given"

read http://www.freedesktop.org/software/systemd/man/systemd.service.html



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] util: fix incorrect escape sequence in string_is_safe()

[Daniel Mack]

On 06/28/2015 07:23 PM, Eric Biggers wrote:
> ---
>  src/basic/util.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/basic/util.c b/src/basic/util.c
> index 727be56..906e4ab 100644
> --- a/src/basic/util.c
> +++ b/src/basic/util.c
> @@ -3627,7 +3627,7 @@ bool string_is_safe(const char *p) {
>  if (*t > 0 && *t < ' ')
>  return false;
>  
> -if (strchr("\\\"\'\0x7f", *t))
> +if (strchr("\\\"\'\x7f", *t))
>  return false;
>  }
>  
> 

Applied, thanks!



Daniel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel