Re: [systemd-devel] Having my script blocking all other scripts until it ends

[Luca Bertoncello]

Hi

> That's correct; units are stopped in reverse order. If your script starts as 
> first,
> it will be stopped as last.

In my case, my scripts starts as last and will be stopped (almost) as first...

> > So the question: how can I have my script BLOCK all other processes until it
> ends?
> >
> 
> Could you rephrase this question?

Well, my script does something that require time and all other processes on the 
server MUST run during this operation.
But right now, after systemd execute my "stop script", it prosecute and stop 
all other processes at the same time (or almost).

Then my question: how can I block the "shutdown process" until my script is 
done?

Thanks

Mit freundlichen Grüßen

Luca Bertoncello

-- 
Besuchen Sie unsere Webauftritte:

www.queo.bizAgentur für Markenführung und Kommunikation
www.queoflow.comIT-Consulting und Individualsoftwareentwicklung

Luca Bertoncello
Administrator
Telefon:+49 351 21 30 38 0
Fax:+49 351 21 30 38 99
E-Mail: l.bertonce...@queo-group.com

queo GmbH
Tharandter Str. 13
01159 Dresden
Sitz der Gesellschaft: Dresden
Handelsregistereintrag: Amtsgericht Dresden HRB 22352
Geschäftsführer: Rüdiger Henke, André Pinkert
USt-IdNr.: DE234220077
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running a script as FIRST script before shutdown

[Mantas Mikulėnas]

On Thu, Sep 24, 2015, 09:40 Luca Bertoncello 
wrote:

> Hi Lennart,
>
> thank you for your answer!
>
> > There is no concept of "first" or "last" in systemd, since it's not
> clear what
> > that's supposed to mean if there are multiple, and what happens if some
> > operation results in activation?
>
> That's bad... :)
>
> > Hence, simply order your service against the services it requires. If
> you want
> > to just run some code when shutting down, make it a service with
> > Type=oneshot and RemainAfterExit=yes, give it an empty ExecStart=, but
> > specify ExecStop= to whatever it's supposed to do. Then order it *after*
> the
> > services that it shall be able to use, as the shutdown order in systemd
> is
> > always the inverse of the startup order, and what you specify via After=
> and
> > Before= specifies the startup order.
>
> Well, this is what I tried for more the three days... :(
> I know, that the script need at least vdsmd.service, vdsm-network.service
> and libvirtd.service.
> But it needs that the tmpfs-partition /run is mounted, too.
> I didn't found any service or target that mount/unmount /run. How can I
> specify it?
>

Well it's not a target nor a service – it's a mount. Therefore
"Requires=run.mount".

However /run will always be available on systemd systems, anyway. (That's
basically the whole point of /run…)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] s390: add personality support

[Hendrik Brueckner]

Introduce personality support for Linux on z Systems to run
particular services with a 64-bit or 31-bit personality.

---
 Makefile.am|1 +
 src/basic/util.c   |   27 +++
 src/test/test-execute.c|8 ++--
 test/exec-personality-s390.service |7 +++
 4 files changed, 41 insertions(+), 2 deletions(-)
 create mode 100644 test/exec-personality-s390.service

diff --git a/Makefile.am b/Makefile.am
index 41bfdfb..e9ad723 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1502,6 +1502,7 @@ EXTRA_DIST += \
test/exec-ignoresigpipe-yes.service \
test/exec-personality-x86-64.service \
test/exec-personality-x86.service \
+   test/exec-personality-s390.service \
test/exec-privatedevices-no.service \
test/exec-privatedevices-yes.service \
test/exec-privatetmp-no.service \
diff --git a/src/basic/util.c b/src/basic/util.c
index 18be0bf..40a4b8f 100644
--- a/src/basic/util.c
+++ b/src/basic/util.c
@@ -5261,6 +5261,19 @@ unsigned long personality_from_string(const char *p) {
 
 if (streq(p, "x86"))
 return PER_LINUX;
+
+#elif defined(__s390x__)
+
+if (streq(p, "s390"))
+return PER_LINUX32;
+
+if (streq(p, "s390x"))
+return PER_LINUX;
+
+#elif defined(__s390__)
+
+if (streq(p, "s390"))
+return PER_LINUX;
 #endif
 
 return PERSONALITY_INVALID;
@@ -5280,6 +5293,20 @@ const char* personality_to_string(unsigned long p) {
 
 if (p == PER_LINUX)
 return "x86";
+
+#elif defined(__s390x__)
+
+if (p == PER_LINUX)
+return "s390x";
+
+if (p == PER_LINUX32)
+return "s390";
+
+#elif defined(__s390__)
+
+if (p == PER_LINUX)
+return "s390";
+
 #endif
 
 return NULL;
diff --git a/src/test/test-execute.c b/src/test/test-execute.c
index dd8ab7d..fa6336f 100644
--- a/src/test/test-execute.c
+++ b/src/test/test-execute.c
@@ -77,10 +77,14 @@ static void test_exec_workingdirectory(Manager *m) {
 }
 
 static void test_exec_personality(Manager *m) {
-test(m, "exec-personality-x86.service", 0, CLD_EXITED);
-
 #if defined(__x86_64__)
 test(m, "exec-personality-x86-64.service", 0, CLD_EXITED);
+
+#elif defined(__s390__)
+test(m, "exec-personality-s390.service", 0, CLD_EXITED);
+
+#else
+test(m, "exec-personality-x86.service", 0, CLD_EXITED);
 #endif
 }
 
diff --git a/test/exec-personality-s390.service 
b/test/exec-personality-s390.service
new file mode 100644
index 000..f3c3b03
--- /dev/null
+++ b/test/exec-personality-s390.service
@@ -0,0 +1,7 @@
+[Unit]
+Description=Test for Personality=s390
+
+[Service]
+ExecStart=/bin/sh -c 'echo $(uname -m); exit $(test $(uname -m) = "s390")'
+Type=oneshot
+Personality=s390
-- 
1.7.1

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

[systemd-devel] RFC: removing initctl support

[e-mail j.deboynepollard-newsgroups]

Lennart Poettering:
> We already declared the interface "obsolete" in the docs, which makes me
> particularly keen on dropping it...

You've heard from the Debian systemd maintainers. You haven't heard from
the Debian sysvinit maintainers. Their subtly different position on
/run/initctl, exemplified by Roger Leigh (one of those maintainers) writing in
2012, is this:

> The protocol is private and undocumented, so there should be
> no third-party users. The location is hard-coded directly into the
> binaries and is likely only intended to be used by sysvinit
> binaries. systemd is an exception to this rule, and I would
> suspect the only one.
-- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657990#57

M. Leigh's suspicion is wrong today, however. The nosh package and Joachim
Nilsson's finit both also have compatibility shims that listen on /dev/initctl
or /run/initctl .  See http://superuser.com/a/888936/38062 for more information.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] s390: add personality support

[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

[systemd-devel] Multiple starts of a service, what am I doing wrong?

[D.S. Ljungmark]

I've got the following unit:

[Unit]
Description=Random Submitter
Wants=network-online.target
After=network-online.target other.service
RequiresMountsFor=/data

[Service]
Type=simple
Environment=PYTHONPATH=/data
PrivateTmp=false
# Launches client config and others if needed
ExecStartPre=/usr/bin/pre-submitter
ExecStart=/usr/bin/random-submitter
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target



With the following path unit activation:

[Path]
PathExists=/data/certificate.crt
PathExists=/data/submitter.ini

[Install]
WantedBy=multi-user.target


Status tells us:

● submitter.service - Random Submitter
Loaded: loaded (/data/systemd/submitter.service; enabled)
Active: active (running) since Wed 2015-09-23 20:20:34 UTC; 13h ago
Process: 6217 ExecStartPre=/usr/bin/pre-submitter (code=exited,
status=0/SUCCESS)
Main PID: 6225 (python3)
CGroup: /system.slice/submitter.service
└─6225 python3 /usr/bin/random-submitter

Sep 24 10:17:53 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:53 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.


And the logs contain... a TON.. of those "started" messages.

journalctl --since -13h -u submitter |grep "Started" |wc -l

24341

So. What have I done wrong here?
(Systemd 215 on Debian)


-- 
8362 CB14 98AD 11EF CEB6 FA81 FCC3 7674 449E 3CFC



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running a script as FIRST script before shutdown

[Andrei Borzenkov]

On Thu, Sep 24, 2015 at 10:41 AM, Luca Bertoncello
 wrote:
> Hi Andrei,
>
>  > Try RequiresMountsFor=/run/whatever
>
> Not enough...
> Currently I have:
>
> [Unit]
> Description=TEST - oVirt interface for managing host
> After=local-fs.target network.target vdsmd.service vdsm-network.service 
> libvirtd.service libvirt-guests.service
> Wants=local-fs.target network.target vdsmd.service vdsm-network.service 
> libvirtd.service libvirt-guests.service
> RequiresMountsFor=/run
>
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/usr/local/bin/ovirt-maintenance.sh active
> ExecStop=/usr/local/bin/ovirt-maintenance.sh maintenance
> KillMode=none
> StandardOutput=syslog+console
>
> [Install]
> WantedBy=multi-user.target
>
> But on Shutdown the system first stops other services and umount /run, and 
> then call my script...

/run is API mount and systemd should not be unmounting it at all. Do
you have any chance to run serial or net console so you can capture
output at shutdown?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running a script as FIRST script before shutdown

[Luca Bertoncello]

> > But on Shutdown the system first stops other services and umount /run,
> and then call my script...
> 
> /run is API mount and systemd should not be unmounting it at all. Do you
> have any chance to run serial or net console so you can capture output at
> shutdown?

Unfortunately not...
I can just think, that this ist he problem, since I can see in the Logs of 
vdsm, errors about "file not found", that is in /run...

Thanks

Mit freundlichen Grüßen

Luca Bertoncello

-- 
Besuchen Sie unsere Webauftritte:

www.queo.bizAgentur für Markenführung und Kommunikation
www.queoflow.comIT-Consulting und Individualsoftwareentwicklung

Luca Bertoncello
Administrator
Telefon:+49 351 21 30 38 0
Fax:+49 351 21 30 38 99
E-Mail: l.bertonce...@queo-group.com

queo GmbH
Tharandter Str. 13
01159 Dresden
Sitz der Gesellschaft: Dresden
Handelsregistereintrag: Amtsgericht Dresden HRB 22352
Geschäftsführer: Rüdiger Henke, André Pinkert
USt-IdNr.: DE234220077
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Having my script blocking all other scripts until it ends

[Andrei Borzenkov]

2015-09-24 11:15 GMT+03:00 Luca Bertoncello :
> Hi again!
>
> So, I got my script starting "as first" (or at least before other services), 
> but the problem is, that the other services, needed from my script, will be 
> shutted down before my script ends...

That's correct; units are stopped in reverse order. If your script
starts as first, it will be stopped as last.

> So the question: how can I have my script BLOCK all other processes until it 
> ends?
>

Could you rephrase this question?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running a script as FIRST script before shutdown

[Luca Bertoncello]

Hi Lennart,

thank you for your answer!

> There is no concept of "first" or "last" in systemd, since it's not clear what
> that's supposed to mean if there are multiple, and what happens if some
> operation results in activation?

That's bad... :)

> Hence, simply order your service against the services it requires. If you want
> to just run some code when shutting down, make it a service with
> Type=oneshot and RemainAfterExit=yes, give it an empty ExecStart=, but
> specify ExecStop= to whatever it's supposed to do. Then order it *after* the
> services that it shall be able to use, as the shutdown order in systemd is
> always the inverse of the startup order, and what you specify via After= and
> Before= specifies the startup order.

Well, this is what I tried for more the three days... :(
I know, that the script need at least vdsmd.service, vdsm-network.service and 
libvirtd.service.
But it needs that the tmpfs-partition /run is mounted, too.
I didn't found any service or target that mount/unmount /run. How can I specify 
it?

Thanks

Mit freundlichen Grüßen

Luca Bertoncello

-- 
Besuchen Sie unsere Webauftritte:

www.queo.bizAgentur für Markenführung und Kommunikation
www.queoflow.comIT-Consulting und Individualsoftwareentwicklung

Luca Bertoncello
Administrator
Telefon:+49 351 21 30 38 0
Fax:+49 351 21 30 38 99
E-Mail: l.bertonce...@queo-group.com

queo GmbH
Tharandter Str. 13
01159 Dresden
Sitz der Gesellschaft: Dresden
Handelsregistereintrag: Amtsgericht Dresden HRB 22352
Geschäftsführer: Rüdiger Henke, André Pinkert
USt-IdNr.: DE234220077
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Having my script blocking all other scripts until it ends

[Luca Bertoncello]

Hi again!

So, I got my script starting "as first" (or at least before other services), 
but the problem is, that the other services, needed from my script, will be 
shutted down before my script ends...
So the question: how can I have my script BLOCK all other processes until it 
ends?

Thanks a lot

Mit freundlichen Grüßen

Luca Bertoncello

-- 
Besuchen Sie unsere Webauftritte:

www.queo.bizAgentur für Markenführung und Kommunikation
www.queoflow.comIT-Consulting und Individualsoftwareentwicklung

Luca Bertoncello
Administrator
Telefon:+49 351 21 30 38 0
Fax:+49 351 21 30 38 99
E-Mail: l.bertonce...@queo-group.com

queo GmbH
Tharandter Str. 13
01159 Dresden
Sitz der Gesellschaft: Dresden
Handelsregistereintrag: Amtsgericht Dresden HRB 22352
Geschäftsführer: Rüdiger Henke, André Pinkert
USt-IdNr.: DE234220077
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running a script as FIRST script before shutdown

[Andrei Borzenkov]

On Thu, Sep 24, 2015 at 9:40 AM, Luca Bertoncello
 wrote:
>
> Well, this is what I tried for more the three days... :(
> I know, that the script need at least vdsmd.service, vdsm-network.service and 
> libvirtd.service.
> But it needs that the tmpfs-partition /run is mounted, too.
> I didn't found any service or target that mount/unmount /run. How can I 
> specify it?
>

Try RequiresMountsFor=/run/whatever
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Martin Pitt]

Hello all,

sorry for the late reply, I've been swamped with other stuff recently.

Lennart Poettering [2015-09-22  2:31 +0200]:
> a) there's support in systemctl to reboot the system by sending the
>right bytes to /dev/initctl as fallback, so that you can reboot a
>sysvinit system with "systemctl reboot".

We indeed need this for upgrades: If you e. g. install Ubuntu 14.04
LTS (with upstart), or Debian Jessie (with SysV init) and install the
systemd packages during the upgrade, you need to be able to reboot
into the upgraded system (while upstart/sysvinit is still running). So
indeed it's only needed exactly once, but we need to keep this around
until at least April 2016 when Ubuntu 16.04 LTS will release (and then
we can reasonably assume that systemd will be running for any further
upgrades).

On Debian it's much harder to give a precise time line as the official
project decision is still to support multiple init systems. But if
there's a documented workaround, that'd also suffice.

> b) There's a mini-daemon "systemd-initctl.service" that is
>fifo-activated on /dev/initctl, and forwards reboot requests from
>old sysvinit clients to systemd.

This direction seems much less important to me -- you can always call
"systemctl reboot" while systemd is pid 1, no?

> We never even really used this stuff on Fedora properly (since we
> actually transitioned from Upstart, not sysvinit, and we never had the
> same level of compat for that...).

You should run into the same problem if you upgrade an upstart system
to systemd, no? You can't possibly exec systemd over upstart in a
running system.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Lennart Poettering]

On Thu, 24.09.15 13:18, Jonathan de Boyne Pollard 
(j.deboynepollard-newsgro...@ntlworld.com) wrote:

> In an ideal world you would be able to have a routine that detected the 
> running
> system manager, and then did whatever was appropriate to that system manager 
> to
> power off, from sending signals to process #1 through running the System 5
> init/rc clone's "shutdown -h -P now" command to sending requests to upstart's
> Desktop Bus API.  In the real world, all of the problems that make detecting 
> the
> running system manager really difficult to do that are described at
> http://unix.stackexchange.com/a/196252/5132 rear their ugly heads.  (A further
> problem not mentioned there: Joachim Nilsson's finit also responds to "initctl
> version".)

That stackexchange link lists a pile of garbage. We have an official
API to check whether the system is booted with systemd:
sd_booted(). It's documented here:

http://www.freedesktop.org/software/systemd/man/sd_booted.html

And we even document on that man page what precisely it does
internally (which is equivalent to access("/run/systemd/system/",
F_OK) >= 0) and suggest people to reimplement that simple check in the
language of their choice, even in shell... That way, they don't even
have to link against libsystemd.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implicit unit dependency on slice might be too weak ?

[Francis Moreau]

On 09/22/2015 03:52 PM, Lennart Poettering wrote:
> On Mon, 21.09.15 16:50, Francis Moreau (francis.m...@gmail.com) wrote:
> 
>> Hi,
>>
>> If a unit depends on a slice, a Wants=machine.slice is automatically
>> added to the unit constraints.
>>
>> Why is "Requires=machine.slice" not prefered instead ?
> 
> I think I agree, we should really make this a requires.
> 

One thing I noted is that even if the slice failed to start, the slice
is still created by starting the unit belonging to that slice, and the
resource controls are still correctly applied to the slice.

Is that expected that units create slice that they belong to ?

I would have expected the unit fails to start because it couldn't find
the slice.

Thanks.

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

Re: [systemd-devel] Running a script as FIRST script before shutdown

[Lennart Poettering]

On Thu, 24.09.15 09:41, Luca Bertoncello (l.bertonce...@queo-group.com) wrote:

> Hi Andrei,
> 
>  > Try RequiresMountsFor=/run/whatever
> 
> Not enough...
> Currently I have:
> 
> [Unit]
> Description=TEST - oVirt interface for managing host
> After=local-fs.target network.target vdsmd.service vdsm-network.service 
> libvirtd.service libvirt-guests.service
> Wants=local-fs.target network.target vdsmd.service vdsm-network.service 
> libvirtd.service libvirt-guests.service
> RequiresMountsFor=/run
> 
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/usr/local/bin/ovirt-maintenance.sh active
> ExecStop=/usr/local/bin/ovirt-maintenance.sh maintenance
> KillMode=none
> StandardOutput=syslog+console
> 
> [Install]
> WantedBy=multi-user.target
> 
> But on Shutdown the system first stops other services and umount /run, and 
> then call my script...

Well, if that's what happens, then it's certainly not systemd which
unmounts /run. It considers it API, and will never unmount it ever.

Unmounting /run is very much pointless, if you are seeing that
something does that, then fix that something to not do it.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] RFC: removing initctl support

[Jonathan de Boyne Pollard]

Daniel P. Berrange:
> Maybe it wasn't actually upstart, but one of the other init systems.
> I just recall getting a patch from Debian folks to support it via
> the /run/initctl path, rather than /dev, and assumed that was upstart
> related.

It wasn't upstart or one of the other init systems.  It was the System 5 init
(clone) people deciding to move the FIFO into /run in response to a bug report
against it.  Their position, exemplified at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657990#57 , was that it was
their private non-SVID interface that they weren't expecting anyone to use
directly and that they could do that at whim. See
http://superuser.com/a/888936/38062 for more of the story.

Lennart Poettering:
> A simple fall back could be to send SIGRTMIN+4 to PID 1, if
> /dev/initctl is not around.

Daniel P. Berrange: 
> Yep, though we'd have to actually check that PID 1 is systemd, since
> if you run a container with a non-init program as PID 1, we don't
> want to be sending it SIGRTMIN+4 :-)

In an ideal world you would be able to have a routine that detected the running
system manager, and then did whatever was appropriate to that system manager to
power off, from sending signals to process #1 through running the System 5
init/rc clone's "shutdown -h -P now" command to sending requests to upstart's
Desktop Bus API.  In the real world, all of the problems that make detecting the
running system manager really difficult to do that are described at
http://unix.stackexchange.com/a/196252/5132 rear their ugly heads.  (A further
problem not mentioned there: Joachim Nilsson's finit also responds to "initctl
version".)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Multiple starts of a service, what am I doing wrong?

[Daniel Mack]

On 09/24/2015 01:17 PM, D.S. Ljungmark wrote:
> I've got the following unit:
> 
> [Unit]
> Description=Random Submitter
> Wants=network-online.target
> After=network-online.target other.service
> RequiresMountsFor=/data
> 
> [Service]
> Type=simple

Type=simple implies that the executable specified through ExecStart= is
the main process and that it does not fork but 'block'. Is that the
case? If it does fork, like most daemons do, Type= should be set to
'forking'.

Or do you actually want to run that binary just once, without systemd
restarting it after it died? That you should set Type= to 'oneshot'.

See systemd.service(5) for more information.


HTH,
Daniel

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

Re: [systemd-devel] Running a script as FIRST script before shutdown

[Lennart Poettering]

On Thu, 24.09.15 08:40, Luca Bertoncello (l.bertonce...@queo-group.com) wrote:

> Hi Lennart,
> 
> thank you for your answer!
> 
> > There is no concept of "first" or "last" in systemd, since it's not clear 
> > what
> > that's supposed to mean if there are multiple, and what happens if some
> > operation results in activation?
> 
> That's bad... :)
> 
> > Hence, simply order your service against the services it requires. If you 
> > want
> > to just run some code when shutting down, make it a service with
> > Type=oneshot and RemainAfterExit=yes, give it an empty ExecStart=, but
> > specify ExecStop= to whatever it's supposed to do. Then order it *after* the
> > services that it shall be able to use, as the shutdown order in systemd is
> > always the inverse of the startup order, and what you specify via After= and
> > Before= specifies the startup order.
> 
> Well, this is what I tried for more the three days... :(
> I know, that the script need at least vdsmd.service, vdsm-network.service and 
> libvirtd.service.
> But it needs that the tmpfs-partition /run is mounted, too.

/run itself is mounted as tmpfs by PID 1 very early on. Much like /sys
or /proc it's considered an API file system, and thus unconditionally
available.

If systemd is used this implies that /run is mounted as a tmpfs, and
that is done before the first userspace process that's not PID 1 is
started.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Multiple starts of a service, what am I doing wrong?

[D.S. Ljungmark]

(re-send due to wrong email address)

On 24/09/15 14:38, Daniel Mack wrote:
> On 09/24/2015 01:17 PM, D.S. Ljungmark wrote:
>> I've got the following unit:
>>
>> [Unit]
>> Description=Random Submitter
>> Wants=network-online.target
>> After=network-online.target other.service
>> RequiresMountsFor=/data
>>
>> [Service]
>> Type=simple
> 
> Type=simple implies that the executable specified through ExecStart= is
> the main process and that it does not fork but 'block'. Is that the
> case? If it does fork, like most daemons do, Type= should be set to
> 'forking'.
> 
> Or do you actually want to run that binary just once, without systemd
> restarting it after it died? That you should set Type= to 'oneshot'.
> 
> See systemd.service(5) for more information.


That is correct. ExecStartPre does some environment/Testing, while the
actual submitter will run fpr ~20 hours, slowly doing network chatter,
and abort in case of network error (trusting systemd to restart it)

So, it's a daemon that never forks.

The question I have isn't about this running or not (it runs
beautifully, gets restarted when it should, and starts once it has a
certificate available)

However, systemd is _spewing_ out this "started service" message, even
while it's already running.

And that's what I'm trying to figure out.

//D.S.

-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC


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

Re: [systemd-devel] RFC: removing initctl support

[Tomasz Torcz]

On Thu, Sep 24, 2015 at 03:01:21PM +0200, Lennart Poettering wrote:
> That stackexchange link lists a pile of garbage. We have an official
> API to check whether the system is booted with systemd:
> sd_booted(). It's documented here:
> 
> http://www.freedesktop.org/software/systemd/man/sd_booted.html
> 
> And we even document on that man page what precisely it does
> internally (which is equivalent to access("/run/systemd/system/",
> F_OK) >= 0) and suggest people to reimplement that simple check in the
> language of their choice, even in shell... That way, they don't even
> have to link against libsystemd.

  And then there is this sabotage:

„This check is already broken, because uselessd creates this directory too”

uselessd% git grep 'mkdir.*/run/systemd/system'
src/core/main-no-init.c:mkdir_label("/run/systemd/system", 0755);
src/core/mount-setup.c:mkdir_label("/run/systemd/system", 0755);
src/core/unit.c:mkdir_p("/run/systemd/system", 0755);

  Meh.

-- 
Tomasz Torcz"Funeral in the morning, IDE hacking
xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox

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

Re: [systemd-devel] RFC: removing initctl support

[Lennart Poettering]

On Thu, 24.09.15 15:51, Tomasz Torcz (to...@pipebreaker.pl) wrote:

> On Thu, Sep 24, 2015 at 03:01:21PM +0200, Lennart Poettering wrote:
> > That stackexchange link lists a pile of garbage. We have an official
> > API to check whether the system is booted with systemd:
> > sd_booted(). It's documented here:
> > 
> > http://www.freedesktop.org/software/systemd/man/sd_booted.html
> > 
> > And we even document on that man page what precisely it does
> > internally (which is equivalent to access("/run/systemd/system/",
> > F_OK) >= 0) and suggest people to reimplement that simple check in the
> > language of their choice, even in shell... That way, they don't even
> > have to link against libsystemd.
> 
>   And then there is this sabotage:
> 
> „This check is already broken, because uselessd creates this directory too”
> 
> uselessd% git grep 'mkdir.*/run/systemd/system'
> src/core/main-no-init.c:mkdir_label("/run/systemd/system", 0755);
> src/core/mount-setup.c:mkdir_label("/run/systemd/system", 0755);
> src/core/unit.c:mkdir_p("/run/systemd/system", 0755);
> 
>   Meh.

Why would anyone care? It's not that anyone was actually using
this... Also, by doing this, that software explicitls *wants* to be
treated like systemd, hence why not let it?

If people focus on weird init systems like that, that's certainly
their own fault...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] s390: add personality support

[Lennart Poettering]

On Thu, 24.09.15 12:47, Hendrik Brueckner (brueck...@linux.vnet.ibm.com) wrote:

> Introduce personality support for Linux on z Systems to run
> particular services with a 64-bit or 31-bit personality.

Merged via:

https://github.com/systemd/systemd/pull/1370

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Daniel P. Berrange]

On Thu, Sep 24, 2015 at 03:51:16PM +0200, Tomasz Torcz wrote:
> On Thu, Sep 24, 2015 at 03:01:21PM +0200, Lennart Poettering wrote:
> > That stackexchange link lists a pile of garbage. We have an official
> > API to check whether the system is booted with systemd:
> > sd_booted(). It's documented here:
> > 
> > http://www.freedesktop.org/software/systemd/man/sd_booted.html
> > 
> > And we even document on that man page what precisely it does
> > internally (which is equivalent to access("/run/systemd/system/",
> > F_OK) >= 0) and suggest people to reimplement that simple check in the
> > language of their choice, even in shell... That way, they don't even
> > have to link against libsystemd.
> 
>   And then there is this sabotage:
> 
> „This check is already broken, because uselessd creates this directory too”
> 
> uselessd% git grep 'mkdir.*/run/systemd/system'
> src/core/main-no-init.c:mkdir_label("/run/systemd/system", 0755);
> src/core/mount-setup.c:mkdir_label("/run/systemd/system", 0755);
> src/core/unit.c:mkdir_p("/run/systemd/system", 0755);

Well if it wants to claim to be systemd, then it is responsible for
providing the same API/ABIs as systemd. IOW it must respond to SIGRTMIN+4
in the same way, etc.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Having my script blocking all other scripts until it ends

[Vivenzio Pagliari]

On 2015-09-24 10:39:33, EXT Luca Bertoncello wrote:
> 
> > Could you rephrase this question?
> 
> Well, my script does something that require time and all other processes
> on the server MUST run during this operation.
>
> But right now, after systemd execute my "stop script", it prosecute and
> stop all other processes at the same time (or almost).
> 
>
> Then my question: how can I block the "shutdown process" until my script
> is done?

Is your service that shall block the subsequent ones in shutdown of Type
"oneshot". I'd expect that the same that is valid for startup is also valid
for shutdown. Quoting systemd.service(5) manpage:

  Type=
[...]
Behavior of oneshot is similar to simple; however, it is expected that
the process has to exit before systemd starts follow-up units.

This implies "blocking behaviour", AFAIU.

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