Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Mon, 21.12.15 22:41, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> On Mon, Dec 21, 2015 at 10:18:05PM +0100, Kai Krakow wrote:
> > Thus: Please maintainers and developers, remove it. Do not let Lennart
> > remove this useful option to force others into removing your shitty
> > cruft.
> 
> This is exactly why systemd is the top one most hated piece of open
> source software. We are not here to be educated about the one and only
> right way of doing things.
> 
> Unix used to be about choice.
> 
> Too bad that we allowed this to be no longer the case. Linux is no
> longer about choice. Linux nowadays is about what the systemd people
> want.
> 
> Too bad that we gave the systemd people the power of forcing us to run
> our systems their way.
> 
> Man kann manchmal echt nicht genug essen wie man in dieser Welt kotzen
> möchte.

You are now on moderation.

Please find a different forum for this systemd hate stuff,
systemd-devel is not it. I'll allow your technical mails onto the ML,
but not the hate BS, take that elsewhere.

Thanks,

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] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Fri, 18.12.15 17:00, Michael Biebl (mbi...@gmail.com) wrote:

> I do think that overriding the complete ExecStart= line is usually
> suboptimal and not what you want if you just want to pass additional
> options to the daemon.
> 
> Maybe a good middle ground / recommendation for such daemons would be,
> to ship a line
> 
> ExecStart=/usr/sbin/foobard $OPTS
> 
> and then tell admin to use systemctl edit
> [Unit]
> Environment=OPTS=-baz
> 
> bonus points if we could standardise the $OPTS var name across
> daemons.

Well, I think the time would be better spent on fixing the daemons to
put their configuration in native config files, so that the process
command line becomes irrelevant.

In the httpd case, I figure it would make sense if Fedora would just
ship a httpd@.service template whose instance name is used on a "-D"
switch or so... Multi-instantiable services are certainly a good idea
in many cases, in particular for web servers...

You know, I am fully aware that there will always be cases where
specific users want to change the cmdline of some random daemon. I
think the goal should be though that that's not the default case, but
very much the exception, and an exception where patching the command
line in the unit file is then fine. But introducing this $OPTS stuff
puts something in the focus of configuration that really shouldn't
be. If you regularly change the command line of a daemon on your
setups, then that's an indication that the daemon is misuing the
command line and should get better configuraiton files. And if you
only do it in exceptional cases, then editing the ExecStart= line is
completely fine and needs no concept of redirection.

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] systemd (user) and (sd-pam) (user) processes in login shell

[Reindl Harald]

Am 23.12.2015 um 01:45 schrieb Lennart Poettering:

On Tue, 22.12.15 01:36, Kai Krakow (hurikha...@gmail.com) wrote:


Am Tue, 8 Dec 2015 01:36:01 +0200
schrieb Mantas Mikulėnas :


What uid does "oracle" have – is it within the system account range
(usually 1–999) or user account (1000–)? I wonder if it's the latter,
which would mean systemd-logind would clean up various things like
IPC on logout... (see logind.conf)


Is this hard-coded in systemd (uid 0..999 and 1000+) or is it read from
login.defs?


We do not read login.defs


which is a mistake


It's a compile-time setting (configure
--with-system-uid-max=). The distros choose the right cutoff, not the
admins


there are setups much older than systemd existed and fedora (as example) 
changed from 500 to 100 - hence a compile time setting is wrong by 
design when there was a config file over many years




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] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Thu, 10.12.15 16:20, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> Am 10.12.2015 um 15:46 schrieb Jóhann B. Guðmundsson:
> >If you are unaware of any other use case for it
> 
> EnvironmentFile=-/etc/sysconfig/httpd
> ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
> 
> [root@testserver:~]$ cat /etc/sysconfig/httpd
> OPTIONS="-D testserver"
> 
> Apache:
> 
> Include "conf/local/testserver.conf"
> 
> 
> and now you can use the same systemd-unit on a dozens of machines and
> include specific config snippets WITOUT touch the systemd-unit or *anything*
> else in the apache configuration

Well, there's not much difference in touching weird env var files or
the unit files themselves. I fail to see what the benefit of not
touching the unit files could be...

Also, what you do above sounds like a job for unit file templates...

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] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 23.12.2015 um 01:32 schrieb Lennart Poettering:

On Fri, 18.12.15 17:00, Michael Biebl (mbi...@gmail.com) wrote:


I do think that overriding the complete ExecStart= line is usually
suboptimal and not what you want if you just want to pass additional
options to the daemon.

Maybe a good middle ground / recommendation for such daemons would be,
to ship a line

ExecStart=/usr/sbin/foobard $OPTS

and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz

bonus points if we could standardise the $OPTS var name across
daemons.


Well, I think the time would be better spent on fixing the daemons to
put their configuration in native config files, so that the process
command line becomes irrelevant.


well, who would go out and change each and every upstream daemon



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] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Sun, 20.12.15 14:30, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote:
> > and then tell admin to use systemctl edit
> > [Unit]
> > Environment=OPTS=-baz
> 
> How would I do the equivalent of systemctl edit with a declarative
> configuration management tool like puppet?

"systemctl edit" is just a helper that simplifies the following common
admin operation:

# mkdir -p /etc/systemd/system/foo.d
# vim /etc/systemd/system/foo.d/override.conf
# systemctl deamon-reload

The drop-ins logic (which this makes use of) is documented in the
man-pages, please have a look.

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] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Tue, 22.12.15 11:27, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 22.12.2015 um 00:16 schrieb Kai Krakow:
> >Back to concepts: I'm always trying to find my way through the new
> >ideas, trying to understand it instead of denying it, then re-apply my
> >workflow. If it doesn't fit, throw either that away, or the software.
> >Probably one of many reasons why I chose Gentoo, although I sometimes
> >play with the idea of trying Fedora. But in the end I would miss much
> >of the freedom I currently have (and make use of)
> 
> so i do, but for what i have *zero* understanding is deperecating and
> removing features which are working just because someone thinks they should
> not be used

Just to clarify that. I think EnvironmentFile= was a mistake, and I
explained why. But then again, I am not planning to remove it, and I
never suggested that.

(I also think you are misusing it in your examples, and there are
better ways to do what you want. Templates and stuff for
example...)

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] systemd (user) and (sd-pam) (user) processes in login shell

[Lennart Poettering]

On Tue, 22.12.15 01:36, Kai Krakow (hurikha...@gmail.com) wrote:

> Am Tue, 8 Dec 2015 01:36:01 +0200
> schrieb Mantas Mikulėnas :
> 
> > What uid does "oracle" have – is it within the system account range
> > (usually 1–999) or user account (1000–)? I wonder if it's the latter,
> > which would mean systemd-logind would clean up various things like
> > IPC on logout... (see logind.conf)
> 
> Is this hard-coded in systemd (uid 0..999 and 1000+) or is it read from
> login.defs?

We do not read login.defs. It's a compile-time setting (configure
--with-system-uid-max=). The distros choose the right cutoff, not the
admins.

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] Policy Routing on a machine using systemd-networkd

[Brendan Horan]

- On 20 Dec, 2015, at 9:52 PM, Marc Haber mh+systemd-de...@zugschlus.de 
wrote:

> *nudge*
> 
> Is there really no option about this rather common issue?

Maybe you can post your work around for policy routing? (if you have one)
I would love to know as well.



> 
> Greetings
> Marc
> 
> 
> On Tue, Dec 15, 2015 at 01:20:34PM +0100, Marc Haber wrote:
>> I would like to do policy routing on a router with ~ 10 interfaces
>> running Debian Linux and systemd. Networking is managed with ferm and
>> systemd-networkd.
>> 
>> I now need Policy Routing. What is the recommended way to handle the
>> usual knot of iptables, ip rule and ip route statement in a clear and
>> beautiful way in a systemd environment?
>> 
>> As far as I know, systemd-network has not yet implemented policy
>> routing, so the canonical way (for me, as a systemd newbie) to
>> implement this would be a sysv init script containing the needed
>> commands.
>> 
>> What would be the "correct" way to do this in a systemd setup?
>> 
>> Actually, I need something that does the following:
>> 
>> o prevent a default route from being present in the main table (either
>>   by preventing it from being set in the first place or removing it
>>   idempotently)
>> o Establish a number of iptables rules to set fwmarks
>> o Establish a number of extra routing tables with a set of rules
>> o Establish a number of ip rule rules regarding source IP ranges or
>>   fwmarks.
>> 
>> How would I do that in systemd? Am I doing ok with a Type=oneshot
>> service unit with a bunch of ExecStart Options? Or is there another
>> recommended way?
> 
> --
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 23.12.2015 um 01:24 schrieb Lennart Poettering:

On Thu, 10.12.15 16:20, Reindl Harald (h.rei...@thelounge.net) wrote:


Am 10.12.2015 um 15:46 schrieb Jóhann B. Guðmundsson:

If you are unaware of any other use case for it


EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND

[root@testserver:~]$ cat /etc/sysconfig/httpd
OPTIONS="-D testserver"

Apache:

Include "conf/local/testserver.conf"


and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or *anything*
else in the apache configuration


Well, there's not much difference in touching weird env var files or
the unit files themselves. I fail to see what the benefit of not
touching the unit files could be...

Also, what you do above sounds like a job for unit file templates...


since the functionality already exists and i am not a distribution "i am 
comfortable with it for years" should be enough - don't fix things which 
ain't broken




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] systemd (user) and (sd-pam) (user) processes in login shell

[Mike Gilbert]

On Mon, Dec 21, 2015 at 9:54 PM, Kai Krakow  wrote:
> Am Mon, 21 Dec 2015 21:43:24 -0500
> schrieb Mike Gilbert :
>
>> On Mon, Dec 21, 2015 at 7:36 PM, Kai Krakow 
>> wrote:
>> > Am Tue, 8 Dec 2015 01:36:01 +0200
>> > schrieb Mantas Mikulėnas :
>> >
>> >> What uid does "oracle" have – is it within the system account range
>> >> (usually 1–999) or user account (1000–)? I wonder if it's the
>> >> latter, which would mean systemd-logind would clean up various
>> >> things like IPC on logout... (see logind.conf)
>> >
>> > Is this hard-coded in systemd (uid 0..999 and 1000+) or is it read
>> > from login.defs?
>> >
>> > Because I cannot find anything related to it in logind.conf which
>> > leads me to the assumption your reference was about RemoveIPC and
>> > friends only...
>>
>> I rather doubt the numeric value of the oracle UID has anything to do
>> with the problem you are having.
>>
>> With systemd, you really cannot start daemons from an interactive
>> shell. Rather, you need to define a service unit, and call "systemctl
>> start" to start long-running daemons.
>
> I think we are talking different here. My question is a spin-off of the
> OP.

Sorry for the mis-reply.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DSC-statistics-collector fails to start

[Mantas Mikulėnas]

On Tue, Dec 22, 2015 at 12:34 PM, Federico Olivieri 
wrote:

> Hi everybody,
>
> I was wondering if someone has experience with DSC DNS collector. Since
> last week, it fails to start in my server. Below the log output. No idea
> what it could be the problem (I had a look into the script indicated into
> the log message but for me seems ok) Anyone has any clue? :) Thanks!!!
>
> -- Unit dsc-statistics-collector.service has begun starting up.
> Dec 22 10:29:22 raspberrypi dsc-statistics-collector[22066]: Starting DNS
> Statistics Collector (default): dsc-collectorcomplete failure
> Dec 22 10:29:22 raspberrypi dsc-statistics-collector[22066]: Pree.cc:70:
> assertion failed: 'i != rawEnd()'
> Dec 22 10:29:22 raspberrypi systemd[1]: dsc-statistics-collector.service:
> control process exited, code=exited status=134
>

The collector reports a crash in Pree.cc line 70, it's a bug in DSC itself
– not a systemd-related problem.

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 22.12.2015 um 00:16 schrieb Kai Krakow:

Back to concepts: I'm always trying to find my way through the new
ideas, trying to understand it instead of denying it, then re-apply my
workflow. If it doesn't fit, throw either that away, or the software.
Probably one of many reasons why I chose Gentoo, although I sometimes
play with the idea of trying Fedora. But in the end I would miss much
of the freedom I currently have (and make use of)


so i do, but for what i have *zero* understanding is deperecating and 
removing features which are working just because someone thinks they 
should not be used


it's one thing educating distributions, but it's another thing taking 
capabilities away from users which made a decision how to implement 
things because they feel comfortable with that way - it's nobodys 
business to question why one feels comfortable with a way something is 
configured and force to change it





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

[systemd-devel] DSC-statistics-collector fails to start

[Federico Olivieri]

Hi everybody,

I was wondering if someone has experience with DSC DNS collector. Since
last week, it fails to start in my server. Below the log output. No idea
what it could be the problem (I had a look into the script indicated into
the log message but for me seems ok) Anyone has any clue? :) Thanks!!!

-- Unit dsc-statistics-collector.service has begun starting up.
Dec 22 10:29:22 raspberrypi dsc-statistics-collector[22066]: Starting DNS
Statistics Collector (default): dsc-collectorcomplete failure
Dec 22 10:29:22 raspberrypi dsc-statistics-collector[22066]: Pree.cc:70:
assertion failed: 'i != rawEnd()'
Dec 22 10:29:22 raspberrypi systemd[1]: dsc-statistics-collector.service:
control process exited, code=exited status=134
Dec 22 10:29:22 raspberrypi systemd[1]: Failed to start LSB:
dsc-statistics-collector.
-- Subject: Unit dsc-statistics-collector.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit dsc-statistics-collector.service has failed.
--
-- The result is failed.
Dec 22 10:29:22 raspberrypi systemd[1]: Unit
dsc-statistics-collector.service entered failed state.
Dec 22 10:29:22 raspberrypi dsc-statistics-collector[22066]:
/lib/lsb/init-functions: line 30: 22087 Aborted
/sbin/start-stop-daemon $args --chdir "$PWD" --exec $exec --oknodo
--pidfile "$pidfile" -- "$@"
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DSC-statistics-collector fails to start

[Federico Olivieri]

Sorry guys, I'm new in this mailing-list. The debug output suggested this
mail-chain for support. Anyway, don't worry, I' ll find out in some way :)

Federico

2015-12-22 10:57 GMT+00:00 Mantas Mikulėnas :

> On Tue, Dec 22, 2015 at 12:34 PM, Federico Olivieri 
> wrote:
>
>> Hi everybody,
>>
>> I was wondering if someone has experience with DSC DNS collector. Since
>> last week, it fails to start in my server. Below the log output. No idea
>> what it could be the problem (I had a look into the script indicated into
>> the log message but for me seems ok) Anyone has any clue? :) Thanks!!!
>>
>> -- Unit dsc-statistics-collector.service has begun starting up.
>> Dec 22 10:29:22 raspberrypi dsc-statistics-collector[22066]: Starting DNS
>> Statistics Collector (default): dsc-collectorcomplete failure
>> Dec 22 10:29:22 raspberrypi dsc-statistics-collector[22066]: Pree.cc:70:
>> assertion failed: 'i != rawEnd()'
>> Dec 22 10:29:22 raspberrypi systemd[1]: dsc-statistics-collector.service:
>> control process exited, code=exited status=134
>>
>
> The collector reports a crash in Pree.cc line 70, it's a bug in DSC itself
> – not a systemd-related problem.
>
> --
> Mantas Mikulėnas 
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd (user) and (sd-pam) (user) processes in login shell

[Mantas Mikulėnas]

On Tue, Dec 22, 2015 at 2:36 AM, Kai Krakow  wrote:

> Am Tue, 8 Dec 2015 01:36:01 +0200
> schrieb Mantas Mikulėnas :
>
> > What uid does "oracle" have – is it within the system account range
> > (usually 1–999) or user account (1000–)? I wonder if it's the latter,
> > which would mean systemd-logind would clean up various things like
> > IPC on logout... (see logind.conf)
>
> Is this hard-coded in systemd (uid 0..999 and 1000+) or is it read from
> login.defs?
>
> Because I cannot find anything related to it in logind.conf which leads
> me to the assumption your reference was about RemoveIPC and friends
> only...
>

It's set at compile (configure) time – either obtained from the compile
host's login.defs or set with --with-system-uid-max=UID.

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

Re: [systemd-devel] systemd (user) and (sd-pam) (user) processes in login shell

[Mantas Mikulėnas]

On Tue, Dec 22, 2015 at 4:43 AM, Mike Gilbert  wrote:

> On Mon, Dec 21, 2015 at 7:36 PM, Kai Krakow  wrote:
> > Am Tue, 8 Dec 2015 01:36:01 +0200
> > schrieb Mantas Mikulėnas :
> >
> >> What uid does "oracle" have – is it within the system account range
> >> (usually 1–999) or user account (1000–)? I wonder if it's the latter,
> >> which would mean systemd-logind would clean up various things like
> >> IPC on logout... (see logind.conf)
> >
> > Is this hard-coded in systemd (uid 0..999 and 1000+) or is it read from
> > login.defs?
> >
> > Because I cannot find anything related to it in logind.conf which leads
> > me to the assumption your reference was about RemoveIPC and friends
> > only...
>
> I rather doubt the numeric value of the oracle UID has anything to do
> with the problem you are having.
>

It does, as Oracle uses SysV IPC and logind's behavior depends on UID.

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/21/2015 04:36 PM, Michael Biebl wrote:

2015-12-21 17:30 GMT+01:00 Jóhann B. Guðmundsson :

It's an added work to add the environmental line to begin with and it's an

That would be done once, by upstream ideally. The work would be negligible.


Still an added work either upstream/downstream + these still have to be 
maintained/updated which people often neglect to take into consideration.





equal amount of work for administrators to change the environmental line or
the Exec= line(s) so the benefit is none

That is not true when considering upgrades.


You are right but for that particular feature of systemd it's a question 
for distribution/upstream whether it should not that it can.


Transparently updating type unit files on update/upgrades can break 
running system/setups ( especially when it comes down to the security 
options that systemd provides being added to those type unit files, 
people have a hard time getting those right in general let alone taking 
into considerations all the variants of setups out in the wild ) just 
like upstream changes in configuration files for a set of 
daemon/services ( httpd 2.2 vs 2.4 for example ).


Administrators on these parts want to have full control over their 
systems since each downtime can cost significant amount of money for 
their company or clients of their company so this feature is not even 
considered a feature while hobby administrators, devops and plain end 
users might consider this a feature since downtime is irrelevant or less 
important to them and does not cost them money or even their job if it 
happens.


Bottom line some people look at what you pointed out as con for using 
environment to handle daemons startup options not as a feature while 
others might.





With environmental files administrators will have to keep tabs on two files

I specifically didn't talk about EnvironmentFile=, but Environment=


Right I was just pointing out that if the intent is to support multiple 
init system then you must use EnvironmentFile=not Environment= to 
achieve that goal.


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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/23/2015 12:43 AM, Lennart Poettering wrote:

Just to clarify that. I think EnvironmentFile= was a mistake, and I
explained why. But then again, I am not planning to remove it, and I
never suggested that.


What usescases do you see for it's existence.

FYI the longer you take fixing your mistakes the harder it will get.

Arguably you should have a deprecation policy that is aligned on par 
with the feature introduction otherwise it can get nearly impossible 
longer down the line with the building blocks of the core/baseOS to 
deprecate anything.


Especially if you have fallen into the trap of "waiting for the right 
time" since there exist no such thing.


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