Re: [systemd-devel] some services always being killed when stress tests running

[Zizka, Jan (Nokia - CZ/Prague)]

> From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On 
> Behalf Of EXT Han Pingtian
> Sent: Wednesday, April 06, 2016 4:33 AM
> On Fri, Apr 01, 2016 at 09:13:54PM +0200, Lennart Poettering wrote:
> > On Tue, 22.03.16 10:02, Han Pingtian (ha...@linux.vnet.ibm.com) wrote:
> >
> > > But only after about 30 minutes, a lot of systemd services failed
> > > and restarted like this:
> > >
> > > ... ...
> > > [26885.910036] systemd[1]: systemd-journald.service: Failed with result
> 'signal'.
> > > [26885.910218] systemd[1]: systemd-udevd.service: Main process
> > > exited, code=killed, status=9/KILL
> >
> > This indicates that something killed the processes in question with
> > SIGKILL. Quite possibly this was the OOM killer, which was triggered
> > by your stress test? Check the kernel logs if you see anything about
> > that...
> >
> I have seen this problem on another system a while ago. But on all the
> systems which this problem can be reproduced, there isn't any OOM killer
> message can be found in kernel logs. How could we debug this problem?

You could use auditd to monitor the signals and then you will see which 
process have sent the SIGKILL. There is also another method mentioned here:
https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/Finding_the_source_of_signals_on_Linux_with_strace_auditd_or_Systemtap?lang=en

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

[systemd-devel] on the default for, PredictableNetworkInterfaceNames

[Sam Tresler]

>Ifconfig does not show anything useful. lspci might provide something 
I can use to construct it, but I'm >not sure. "dmesg | grep enp3s0" 
confirms this, but I still need to manually construct the entire string.


I didn't make it through the rest of your post, but thought I'd chime in 
with `ifconfig` has been deprecated since 2009.


2009. I don't get deep into the distros, but I really wish they'd stop 
shipping it.


`man ip` should give you info on the right tool you need to retrieve 
your network info. From there it is just some pipework to get a list you 
can iterate over.


$ ip -o a | awk '{print $2}' | uniq




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

[systemd-devel] Call for a small extension - Passing the startup timeout to the processes as environment variable

[Hoyer, Marko (ADITG/SW2)]

Hi Hi,

I'm interested in a small extension around systemd passing a set of environment 
variables to processes executed (mainly what is happening in: 
build_environment(); execute.c)

What are we planning to do:

-  We are planning to have some functionality linked against 
applications started by systemd (in a shared library or so)

-  The purpose of the shared library is to debug out some information 
about the applications state and about the process in general in case

o   The watchdog is not served right in time

o   The READY=1 sd_notify signal is not sent right in time

-  The information must be dumped out before systemd kills the 
applications

To the realization:

-  The involved sd_notify calls are not directly called by the 
application, the application uses an abstraction provided by the shared 
library. The library delegates further respective calls.

o   So we are able to detect when an application serves the watchdog or sends 
the READY=1 signal

-  We need now a way to detect at about 90% of the elapsed timeout that 
the application is not reacting

-  For this, we need to know the watchdog timeout and the startup 
timeout set in the service file

o   The first one is passed as ENVIRONMENT variable by systemd to the processes

o   The second one is not

To the request:

-  Would it be possible to add some code lines to pass the startup 
timeout time as well as ENVIRONMENT variable?

Would be cool.

Thx in advance!

Best regards

Marko Hoyer
Software Group II (ADITG/SW2)

Tel. +49 5121 49 6948

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

[systemd-devel] How to troubleshoot 'step CHDIR spawning' failure.

[MikeB]

>>* I've verified that '/bin/mkdir' does exist and does run fine.  So I assume
*>>* the the 'No such file or directory' refers to the target of the chdir.
*>> >>* My question is how do I troubleshoot from here?  What can I do
to determine
*>>* exactly what file or directory is not being found.  I'd like to understand
*>>* what is wrong and fix it.
*>
>  CHDIR failure points to something related with directory.  Check
> what directives you have in unit file - maybe WorkingDirectory= with
> dir that do not exists? Or RootDirectory= ?
>  Speculating further - maybe you are trying to mkdir directory which
> you also put in RootDirectory= ?  This won't work, because /bin/mkdir is
> run in the same environment that main process; but you can
>  – investigate if PermissionStartOnly= (man systemd.service) will help you
>  – use RuntimeDirectory= (man systemd.service) to automate directory
>creation
>  - use tmpfiles to precreate all directories

Sorry, I should have included the entire contents of the service file.

Your speculation was right on...  hidden among all the commands the the
[Service] section was a WorkingDirectory= statement that I hadn't noticed.
It was, indeed, pointing to a directory that doesn't exist.

Easy fix.  Thank you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] resolved: does DNSSEC=allow-downgrade affect caching?

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 13, 2016 at 04:43:27PM +0300, Ran Benita wrote:
> On Wed, Apr 13, 2016 at 01:04:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Apr 13, 2016 at 02:26:49PM +0300, Ran Benita wrote:
> > > coredumpctl doesn't show the crash so can't say what it's about. Maybe
> > > it's a distro problem (archlinux) or it's fixed in git.
> > 
> > It's probably the bug that was fixed in 
> > https://github.com/systemd/systemd/pull/2702.
> 
> Thanks.
> 
> BTW, this brings up this thought: say I'm a system administrator and I
> set DNSSEC=yes, and rely on it to fail any unauthenticated lookups. If
> resolved crashes for some reason, the nss module will just start using
> the fallback, which probably doesn't fail unauthenticated lookups. So
> it's fail-open, IIUC. Maybe the nss module should look at the DNSSEC=
> setting?

Good point. Definitely something to consider in the long run.

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

Re: [systemd-devel] resolved: does DNSSEC=allow-downgrade affect caching?

[Ran Benita]

On Wed, Apr 13, 2016 at 01:04:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Apr 13, 2016 at 02:26:49PM +0300, Ran Benita wrote:
> > coredumpctl doesn't show the crash so can't say what it's about. Maybe
> > it's a distro problem (archlinux) or it's fixed in git.
> 
> It's probably the bug that was fixed in 
> https://github.com/systemd/systemd/pull/2702.

Thanks.

BTW, this brings up this thought: say I'm a system administrator and I
set DNSSEC=yes, and rely on it to fail any unauthenticated lookups. If
resolved crashes for some reason, the nss module will just start using
the fallback, which probably doesn't fail unauthenticated lookups. So
it's fail-open, IIUC. Maybe the nss module should look at the DNSSEC=
setting?

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

[systemd-devel] Best approach to run python service in virtualenv with systemd

[Stanislav Kopp]

Hi all,

I'm trying to run kallithea using virtualenv, it kinda works (I can
stop/start service) with this unit file


[Unit]
Description=Start Kallithea service
After=network.target

[Service]
Type=forking
User=kallithea
WorkingDirectory=/srv/kallithea
ExecStart=/srv/kallithea/venv/bin/python2
/srv/kallithea/venv/bin/paster serve --daemon
--pid-file=/srv/kallithea/kallithea.pid
--log-file=/srv/kallithea/kallithea.log my.ini
PIDFile=/srv/kallithea/kallithea.pid

[Install]
WantedBy=multi-user.target
#

but I always see "Failed to read PID from file
/srv/kallithea/kallithea.pid: Invalid argument" in "systemctl status",
I know that "PIDFile" option isn't a best practice and should be
avoided, but withou it service doesn't running.
Is there any better methods to run it or at least remove this pid error message?


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

Re: [systemd-devel] resolved: does DNSSEC=allow-downgrade affect caching?

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 13, 2016 at 02:26:49PM +0300, Ran Benita wrote:
> OK, I just looked at the logs and figured out what happens: resolved
> crashes whenever I perform a query with allow-downgrade, and after a few
> times it doesn't restart and presumably the nss module falls back to
> direct DNS queries. Here is the log:
> 
> Apr 13 13:56:31 ran systemd[1]: Started Network Name Resolution.
> Apr 13 13:56:31 ran systemd-resolved[4687]: Switching to DNS server 10.0.0.10 
> for interface wlp3s0.
> Apr 13 13:56:31 ran systemd-resolved[4687]: Using degraded feature set 
> (UDP+EDNS0) for DNS server 10.0.0.10.
> Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for 
> question com. IN SOA: failed-auxiliary
> Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for 
> question google.com. IN DS: failed-auxiliary
> Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for 
> question google.com. IN SOA: failed-auxiliary
> Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for 
> question google.com. IN A: failed-auxiliary
> Apr 13 13:56:31 ran kernel: systemd-resolve[4687]: segfault at 5c ip 
> 55b0062a5c57 sp 7ffee0d320a0 error 4 in 
> systemd-resolved[55b006281000+9d000]
> Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Main process 
> exited, code=killed, status=11/SEGV
> Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Unit entered failed 
> state.
> Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Failed with result 
> 'signal'.
> Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Service has no 
> hold-off time, scheduling restart.
> Apr 13 13:56:31 ran systemd[1]: Stopped Network Name Resolution.
> Apr 13 13:56:31 ran systemd[1]: org.freedesktop.resolve1.busname: Start 
> request repeated too quickly.
> Apr 13 13:56:31 ran systemd[1]: Failed to listen on Network Name Resolution 
> Service Bus Name.
> Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Start request 
> repeated too quickly.
> Apr 13 13:56:31 ran systemd[1]: Failed to start Network Name Resolution.
> 
> coredumpctl doesn't show the crash so can't say what it's about. Maybe
> it's a distro problem (archlinux) or it's fixed in git.

It's probably the bug that was fixed in 
https://github.com/systemd/systemd/pull/2702.

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

Re: [systemd-devel] How to log to journald using fifo?

[Mantas Mikulėnas]

On Wed, Apr 13, 2016 at 2:43 PM, Samuel Williams <
space.ship.travel...@gmail.com> wrote:

> I guess what I'm proposing is not a specific workaround but a way for
> legacy software which can only log to a file to get it's data into
> journald. There is plenty of software like that, unfortunately. It's a
> pragmatic option.
>
> In this specific case, I'm referring to Nginx in daemon mode, which closes
> /dev/stderr as far as I can tell, and then spawns passenger, which can only
> log to a file. There is no way to hook up passenger to /dev/stderr.
>
> The proposed service allows anyone to set up a fifo for logging in this
> situation, it's very trivial and easy to set up, but I suspect there is
> more than just one person with this issue.
>

If you're going to run a service anyway, could you use e.g. rsyslog's
imfile → omjournal modules?

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to troubleshoot 'step CHDIR spawning' failure.

[Tomasz Torcz]

On Wed, Apr 13, 2016 at 07:28:34AM -0400, MikeB wrote:
> I'm running systemd 215 on a fairly up-to-date Debian Jessie system.
> 
> I have a Type=forking service that fails on its first ExecStartPre command
> which is using /bin/mkdir to create a directory.
> 
> The service fails to start with the following.
> 
> Apr 13 10:07:42 localhost systemd[1]: Starting OVSDB Server Daemon...
> Apr 13 10:07:42 localhost systemd[4069]: Failed at step CHDIR spawning
> /bin/mkdir: No such file or directory
> Apr 13 10:07:42 localhost systemd[1]: ovsdb-server.service: control process
> exited, code=exited status=200
> Job for ovsdb-server.service failed. See 'systemctl status
> ovsdb-server.service' and 'journalctl -xn' for details.
> Apr 13 10:07:42 localhost systemd[1]: Failed to start OVSDB Server Daemon.
> Apr 13 10:07:42 localhost systemd[1]: Unit ovsdb-server.service entered
> failed state.
> a
> 
> I've verified that '/bin/mkdir' does exist and does run fine.  So I assume
> the the 'No such file or directory' refers to the target of the chdir.
> 
> My question is how do I troubleshoot from here?  What can I do to determine
> exactly what file or directory is not being found.  I'd like to understand
> what is wrong and fix it.

  CHDIR failure points to something related with directory.  Check
what directives you have in unit file - maybe WorkingDirectory= with
dir that do not exists? Or RootDirectory= ?
  Speculating further - maybe you are trying to mkdir directory which
you also put in RootDirectory= ?  This won't work, because /bin/mkdir is
run in the same environment that main process; but you can
 – investigate if PermissionStartOnly= (man systemd.service) will help you
 – use RuntimeDirectory= (man systemd.service) to automate directory
   creation
 - use tmpfiles to precreate all directories


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.

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

Re: [systemd-devel] How to log to journald using fifo?

[Samuel Williams]

I guess what I'm proposing is not a specific workaround but a way for
legacy software which can only log to a file to get it's data into
journald. There is plenty of software like that, unfortunately. It's a
pragmatic option.

In this specific case, I'm referring to Nginx in daemon mode, which closes
/dev/stderr as far as I can tell, and then spawns passenger, which can only
log to a file. There is no way to hook up passenger to /dev/stderr.

The proposed service allows anyone to set up a fifo for logging in this
situation, it's very trivial and easy to set up, but I suspect there is
more than just one person with this issue.

On 12 April 2016 at 02:21, Lennart Poettering  wrote:

> On Sun, 10.04.16 22:57, Samuel Williams (space.ship.travel...@gmail.com)
> wrote:
>
> > Hello,
> >
> >
> > I've been trying to figure out the best way to support legacy
> applications
> > that don't support syslog for logging. The best we can do, I think, is to
> > use fifo and have another process read the fifo to journald.
>
> Note that on systemd everything logged out stdout or stderr ends up in
> the journal anyway. And you can specify /dev/stderr or /proc/self/fd/2
> as path referring to stderr on Linux generally, if you need.
>
> > Finally, if this is a good approach, is this method worth putting into
> > systemd/journald as a standard service? If so, how do I submit a PR or
> > where to begin?
>
> Specific work-arounds around other, unrelated pieces of software are
> not really what we we'd like to add to systemd directly. Sorry.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to troubleshoot 'step CHDIR spawning' failure.

[MikeB]

I'm running systemd 215 on a fairly up-to-date Debian Jessie system.

I have a Type=forking service that fails on its first ExecStartPre command
which is using /bin/mkdir to create a directory.

The service fails to start with the following.

Apr 13 10:07:42 localhost systemd[1]: Starting OVSDB Server Daemon...
Apr 13 10:07:42 localhost systemd[4069]: Failed at step CHDIR spawning
/bin/mkdir: No such file or directory
Apr 13 10:07:42 localhost systemd[1]: ovsdb-server.service: control process
exited, code=exited status=200
Job for ovsdb-server.service failed. See 'systemctl status
ovsdb-server.service' and 'journalctl -xn' for details.
Apr 13 10:07:42 localhost systemd[1]: Failed to start OVSDB Server Daemon.
Apr 13 10:07:42 localhost systemd[1]: Unit ovsdb-server.service entered
failed state.
a

I've verified that '/bin/mkdir' does exist and does run fine.  So I assume
the the 'No such file or directory' refers to the target of the chdir.

My question is how do I troubleshoot from here?  What can I do to determine
exactly what file or directory is not being found.  I'd like to understand
what is wrong and fix it.

Thanks and Regards,
Mike
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] resolved: does DNSSEC=allow-downgrade affect caching?

[Ran Benita]

OK, I just looked at the logs and figured out what happens: resolved
crashes whenever I perform a query with allow-downgrade, and after a few
times it doesn't restart and presumably the nss module falls back to
direct DNS queries. Here is the log:

Apr 13 13:56:31 ran systemd[1]: Started Network Name Resolution.
Apr 13 13:56:31 ran systemd-resolved[4687]: Switching to DNS server 10.0.0.10 
for interface wlp3s0.
Apr 13 13:56:31 ran systemd-resolved[4687]: Using degraded feature set 
(UDP+EDNS0) for DNS server 10.0.0.10.
Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for 
question com. IN SOA: failed-auxiliary
Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for 
question google.com. IN DS: failed-auxiliary
Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for 
question google.com. IN SOA: failed-auxiliary
Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for 
question google.com. IN A: failed-auxiliary
Apr 13 13:56:31 ran kernel: systemd-resolve[4687]: segfault at 5c ip 
55b0062a5c57 sp 7ffee0d320a0 error 4 in 
systemd-resolved[55b006281000+9d000]
Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Main process exited, 
code=killed, status=11/SEGV
Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Unit entered failed 
state.
Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Failed with result 
'signal'.
Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Service has no 
hold-off time, scheduling restart.
Apr 13 13:56:31 ran systemd[1]: Stopped Network Name Resolution.
Apr 13 13:56:31 ran systemd[1]: org.freedesktop.resolve1.busname: Start request 
repeated too quickly.
Apr 13 13:56:31 ran systemd[1]: Failed to listen on Network Name Resolution 
Service Bus Name.
Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Start request 
repeated too quickly.
Apr 13 13:56:31 ran systemd[1]: Failed to start Network Name Resolution.

coredumpctl doesn't show the crash so can't say what it's about. Maybe
it's a distro problem (archlinux) or it's fixed in git.

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

[systemd-devel] resolved: does DNSSEC=allow-downgrade affect caching?

[Ran Benita]

Hey,

I read in the v229 NEWS that it is now possible to specify
DNSSEC=allow-downgrade and decided to try it. Note that I use my local
home router's DNS server which certainly does not support DNSSEC. I
configured the system to use resolved by changing "dns" to "resolve" in
nsswitch.conf. I use systemd v229.

I use the following simple python to test the DNS response time:

import time, socket;
before = time.time(); socket.gethostbyname('google.com'); after = 
time.time()
print((after - before) * 1000)

With resolved stopped entirely (systemctl stop), I get around ~22ms for
all queries.

With resolved started, and setting DNSSEC=no, I get ~22ms first time,
and ~2m in subsequent queries.

With resolved started, and setting DNSSEC=allow-downgrade, I get ~22ms
consistently after a few times.

So it seems like with allow-downgrade, local caching isn't performed? Is
this expected behavior for this option? Or maybe I did something wrong?
(I am lazy and didn't try to investigate with wireshark and/or the
code).

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

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 13.04.2016 um 02:15 schrieb pgndev:

On Tue, Apr 12, 2016 at 5:06 PM, Reindl Harald  wrote:

Is there a ML anywhere on which you don't sputter, fume, rant and insult?


interesting that you say that to me in this thread while the OP started 
very early to call people "Idiot", "why someone does not do a certain 
thing, you are an idiot" and "are you silly"


given that and that he even admit repeatly that he have no really clue 
about many things which are relevant to the topic and then comes up with 
"well, do a sleep 3" the only correct answer is STOP IT, the whole thread




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

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 13.04.2016 um 03:08 schrieb Xen:

Reindl Harald schreef op 13-04-16 02:06:


Am 13.04.2016 um 01:20 schrieb Xen:

Greg KH schreef op 13-04-16 01:16:

On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote:

All you need to do is wait a few seconds before you start renaming


Most machines boot to login faster than a "few seconds", so:


Most machines boot to login faster than a few seconds?

What machines are you talking about?

Anyway the 3 seconds I mentioned is or would be a relative number


STOP IT NOW


What are you on about?

Just because I don't have a superfast system, I cannot say anything?


no beause of "hmm let wait 3 seconds for something we don't know if it 
ever appears and how long it would take to appear" is unacceptable in 
general as additional boot time and on many setups would double the 
whole boot time


nobody right in his mind would implement a "sleep 3" for a general 
purpose setup in the boot process


*kernel time* is below 1 second on most machines





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

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Reindl Harald]

Am 13.04.2016 um 02:42 schrieb Xen:

Greg KH schreef op 13-04-16 01:29:

On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote:



All execpt for 4-socket and larger servers.  They take tens of minutes
in the BIOS and then less than a minute in the kernel/userspace,
depending on the amount of memory.

Doesn't your laptop/desktop boot that fast?  If not, you are using the
wrong distro :)


I have no SSD. Even a 4-rotating-disk raid-10 system using a relatively
new processor (FX 6300) does definitely not boot within a few seconds


4xHDD raid-10, hardware from 2011
Startup finished in 660ms (kernel) + 5.380s (initrd) + 12.769s 
(userspace) = 18.810s


os on sd-card
Startup finished in 375ms (kernel) + 4.306s (initrd) + 8.323s 
(userspace) = 13.005s


so 3 seconds is unacceptable and the idea ist a joke in general because 
you wait for something possibly happen while you don't know how long you 
have to wait and jsut hope for luck - that's not a good design and won't 
bew accepted anywhere




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