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

[Lennart Poettering]

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

> 
> 
> Am 09.12.2015 um 20:46 schrieb Lennart Poettering:
> >I probably should never have added EnvironmentFile= in the first
> >place. Packagers misunderstand that unit files are subject to admin
> >configuration and should be treated as such, and that spliting out
> >configuration of unit files into separate EnvironmentFiles= is a
> >really non-sensical game of unnecessary indirection
> 
> i strongly disagree
> 
> it's the easiest way to not touch/copy the systemd-unit *and*
> systemd-snippets for just adjust a simple variable - the point here is
> simple

There are very few things that are easier than "systemctl edit" or
"systemctl edit --full"... Also, you have to do that anyway, if you
want to make any changes about the service itself, such as setting a
memory limit, or adding a dep.

> copy units and/or add own snippets has easily two side effects
> 
> * don't get well deserved updates for the units

Sometimes this is precisely what you want, hence you have the choice
between creating a drop-in ("systemctl edit") or copy/edit the full
file ("systemctl edit --full").

> * or snippets don't play well with later dist-versions of the unit
> 
> a EnvironmentFile supported by the distributions unit is well better for
> simple adoptions

Nope, it's an ugly Redhatism... It defeats a good chunk of our
toolset, include systemctl edit to change things, systemctl cat to see
the current state or systemd-delta to diff the settings. Hence it
really was a bad idea to add in the first place.

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 10.12.2015 um 11:15 schrieb Lennart Poettering:

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




Am 09.12.2015 um 20:46 schrieb Lennart Poettering:

I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection


i strongly disagree

it's the easiest way to not touch/copy the systemd-unit *and*
systemd-snippets for just adjust a simple variable - the point here is
simple


There are very few things that are easier than "systemctl edit" or
"systemctl edit --full"... Also, you have to do that anyway, if you
want to make any changes about the service itself, such as setting a
memory limit, or adding a dep.


but that few things are fine


copy units and/or add own snippets has easily two side effects

* don't get well deserved updates for the units


Sometimes this is precisely what you want, hence you have the choice
between creating a drop-in ("systemctl edit") or copy/edit the full
file ("systemctl edit --full").


and sometimes you just want something like
EnvironmentFile=-/etc/sysconfig/httpd

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

to share the whole httpd config between multiple servers


* or snippets don't play well with later dist-versions of the unit

a EnvironmentFile supported by the distributions unit is well better for
simple adoptions


Nope, it's an ugly Redhatism... It defeats a good chunk of our
toolset, include systemctl edit to change things, systemctl cat to see
the current state or systemd-delta to diff the settings. Hence it
really was a bad idea to add in the first place.


well, accept that people adopted that Redhatism long before systemd was 
even planned, working only with RHEL/CentOS/Fedora and hence are happy 
with it and don't need or want to use "systemctl edit" while they accept 
that you like it




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"

[Simon McVittie]

On 09/12/15 19:46, Lennart Poettering wrote:
> Also /etc/sysconfig is a Redhatism
> that should really go away, the whole concept is flawed.

This is by no means limited to Red Hat derivatives: /etc/default is a
Debianism which is basically the same as /etc/sysconfig.

I think Red Hat and Debian derivatives do both over-use their respective
EnvironmentFile directories (and in particular the START_DAEMON=0
anti-pattern, which was a workaround for how hard it traditionally was
to disable a service in sysvinit, needs to go away), but it can make
sense for the specific case of overriding non-system-integration-related
command-line options, to avoid situations like this:

* foobar version 1 has ExecStart=/usr/libexec/foobar --no-fork
* sysadmin overrides that to
  ExecStart=/usr/libexec/foobar --no-fork --enable-uploads
* distribution or upstream changes version 2 to say
  ExecStart=/usr/libexec/foobar --no-fork --use-syslog
  (or some other new system-integration option)
* desired result: --no-fork --use-syslog --enable-uploads
* actual result if the sysadmin has used systemctl edit:
  --no-fork --enable-uploads

by having "ExecStart=/usr/libexec/foobar --no-fork [--use-syslog]
$OPTIONS" instead.

Of course, it would be better for the underlying service to have a
configuration file (or, better, a .d directory) where the sysadmin could
enable uploads; but we have to work with what we have, not what we'd
like to have, and not all underlying services have that.

The approach I try to follow in dbus is that options that should be
changed by another package (such as default security policies) go in a
configuration file, or more recently a file in /usr/share; options that
should be changed by the sysadmin (such as security policies and
resource limits) also go in a configuration file; but system-integration
options (such as "use syslog" or "use systemd for activation") are
command-line options that can be forced to their
correct-for-this-distribution values by the ExecStart line in the
systemd unit, LSB init script or whatever. Unfortunately dbus doesn't
always follow this rule for historical reasons -  is a
configuration-file option, but it shouldn't be.

-- 
Simon McVittie
Collabora Ltd. 

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

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

[Andrei Borzenkov]

10.12.2015 18:44, Jóhann B. Guðmundsson пишет:
> 
> 
> On 12/10/2015 03:20 PM, Reindl Harald 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
> 
> You apparently did not read or grasp what I said earlier.
> 
> This is something you do via unit overwrite configuration snipped in
> conjunction with your Apache configuration changes not in an environment
> file.
> 

Care to show example how it should be done from your point of view? So
that they can actully be compared?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github issue progress stalled

[Colin Guthrie]

Philip Müller wrote on 08/12/15 11:16:
> However I can still see that your "quest" is still open:
> 
> Try connecting with gdb to PID 1 and see which event causes it to wakeup
> all the time. for that set a breakpoint on source_dispatch and look at
> s->description which hopefully contains a short string that tells you
> which source is being triggered there ...

I think I've supplied all that information on the issue no?

Is there something I'm missing?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

___
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 10.12.2015 um 16:44 schrieb Jóhann B. Guðmundsson:

On 12/10/2015 03:20 PM, Reindl Harald 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


You apparently did not read or grasp what I said earlier.

This is something you do via unit overwrite configuration snipped in
conjunction with your Apache configuration changes not in an environment
file.


this is something *i do not* with unit overwrite configuration by 
intention because i DO NOT want to touch ExecStart on any machine



perhaps it's time to
start looking into obsoleting it


don't get me wrong but you sound once again like seek for changes to
break users configuration to later blame users why they did not fix
which ain't broken


You cannot be gotten right.

The follow up cleanup process in Fedora that I needed to conduct after
the unit migration was completed, would have among other things
obsoleted and removed those Fedora/RedHat specific environment files
since it became clear immediately at that time that they had been
obsoleted


cleanup whatever you want in Fedora, i don't use httpd or other server 
packages from the distribution at all - by removing "EnvironmentFile" 
from systemd you piss of users and sysadmins, not only distributions




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] The sixth field (fs_passno) should be zero

[Jonathan de Boyne Pollard]

Dimitri John Ledkov: > Most filesystems support destructive operations, 
with a goal to recover data via some-sort check/repair functionality 
e.g. btrfs check/rescue, xfs_repair etc. > Some filesystems also require 
periodic maintenance calls, e.g. something like the `harmless' fsck on 
each mount. > Some filesystems support both destructive recovery and 
periodic maintainance via fsck interface. > However most filesystems in 
use today, have their own native tooling for destructive recovery and 
don't need periodic maintenance calls. If you'd described this in terms 
of "preen mode", I think that it would have been clearer to other people 
what you are getting at. Dimitri John Ledkov: > At the moment stable 
debian releases configure (well partman, or partman-$foo) mountpoints in 
/etc/fstab with passno set to 1 or 2, which means run "fsck" in a 
priority order. > This leads to a following chain of events on 
filesystems that do not require periodic maintenance and only have their 
own destructive recovery tooling:


(... "that have no-op for preen mode and only have a full interactive, 
non-preen, mode of checking" ...)


Dimitri John Ledkov: > - debian-install sets passno to 1|2 > - 
initramfs-tools includes fsck.$foo scripts > - on each boot these are 
called > - $foo-progs packages ship these fsck.$foo scripts > - and said 
fsck.$foo scripts do nothing > > This is currently the case for xfs and 
btrfs, which imho is silly. > > I'm proposing to do following, for 
filesystems that require no periodic maintainance:


(... "whose fsck tools do nothing for boot-time 'preening' anyway"... )

Dimitri John Ledkov: > - d-i to set passno to 0 > - initramfs-tools to 
not include fsck.$foo tools for passno=0 mountpoints > - not spend time 
on each boot, forking shell scripts that do nothing > - $foo-progs 
packages to stop shipping dummy wrapper scripts fsck.$foo > - on upgrade 
force set passno to zero for filesystems in question > - $foo-progs 
packages to still ship initramfs-tools hooks that include/update 
initramfs with latest disaster recovery tooling (e.g. btrfs 
check/rescue, xfs_repair, e2fsck etc.)


The main thing that this is gaining you is the second bullet point: not 
spending tine forking the fsck.btrfs and xfs_fsck shell scripts that 
print messages and exit 0. Whether that's a major objective is 
debateable, but on the presumption that it is you're spending a lot of 
effort there for something that is achieved more simply.


Don't change anything with the installer or upgrade, and just replace 
the no-op fsck.$fstype scripts with symbolic links to /bin/true . 
systemd has an undocumented mechanism that checks for that, and when it 
is detected as the case both makes systemd-fsck do nothing and doesn't 
bring in the systemd-fsck@.service for the volume in the first place.


* 
http://lists.freedesktop.org/archives/systemd-devel/2014-June/020714.html * 
http://lists.freedesktop.org/archives/systemd-devel/2014-June/020737.html


___
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]

> only wanted to maintain a single unit file but cross
> distribution compatibility and the importance of it
> is something you dont seem to be capable of grasping
> since the only use cases that matters is the one that
> is specific and relevant to you"

no, but you don't grasp that options for systemd-units as well as units 
itself are not only relevant for distributions or upstream but also 
heavily used by sysadmins and that you have *no bussiness* to tell 
somebody "something you do via"


you are free to do that when someone asks for new features, but not in 
case of a planned regression - nothing else is taking features and 
options away


Am 10.12.2015 um 16:47 schrieb Reindl Harald:

Am 10.12.2015 um 16:44 schrieb Jóhann B. Guðmundsson:

On 12/10/2015 03:20 PM, Reindl Harald 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


You apparently did not read or grasp what I said earlier.

This is something you do via unit overwrite configuration snipped in
conjunction with your Apache configuration changes not in an environment
file.


this is something *i do not* with unit overwrite configuration by
intention because i DO NOT want to touch ExecStart on any machine


perhaps it's time to
start looking into obsoleting it


don't get me wrong but you sound once again like seek for changes to
break users configuration to later blame users why they did not fix
which ain't broken


You cannot be gotten right.

The follow up cleanup process in Fedora that I needed to conduct after
the unit migration was completed, would have among other things
obsoleted and removed those Fedora/RedHat specific environment files
since it became clear immediately at that time that they had been
obsoleted


cleanup whatever you want in Fedora, i don't use httpd or other server
packages from the distribution at all - by removing "EnvironmentFile"
from systemd you piss of users and sysadmins, not only distributions




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"

[Jóhann B . Guðmundsson]

On 12/09/2015 07:46 PM, Lennart Poettering wrote:

I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection.




The legacy sys initscripts in Fedora, more or less ( with the exception 
of very few corner cases which got solved via templates ) where just 
using environment files that resided under the /etc/sysconfig directory 
that contained options to match $FOO="Yes" or "No" or Options="Bar" 
which you override either via copy of the type unit file or via 
overwrite snippet.


I personally never saw the reason why it existed in first place ( in 
that context ) and I'm not aware of any other usecase for it's existence 
and I have seen units in various upstreams repos' that contain that 
/etc/sysconfig Fedora/RedHat-ism which at the same time makes them 
incomparable with any other distro thus adds to the upstream/downstream 
burden of maintaining those unit file(s).


If you are unaware of any other use case for it perhaps it's time to 
start looking into obsoleting it.


JBG
___
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 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



perhaps it's time to
start looking into obsoleting it


don't get me wrong but you sound once again like seek for changes to 
break users configuration to later blame users why they did not fix 
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] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/10/2015 03:20 PM, Reindl Harald 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


You apparently did not read or grasp what I said earlier.

This is something you do via unit overwrite configuration snipped in 
conjunction with your Apache configuration changes not in an environment 
file.





perhaps it's time to
start looking into obsoleting it


don't get me wrong but you sound once again like seek for changes to 
break users configuration to later blame users why they did not fix 
which ain't broken




You cannot be gotten right.

The follow up cleanup process in Fedora that I needed to conduct after 
the unit migration was completed, would have among other things 
obsoleted and removed those Fedora/RedHat specific environment files 
since it became clear immediately at that time that they had been 
obsoleted.


We would have done that immediately in F14/F15 when we started the 
migration work but we had other political issues surrounding systemd to 
deal with at that time without having to add the obsolete of those 
legacy sysv initscripts environment files that Redhat holds so dear.


I even created specific git repository without that environment file 
entry's specific to Redhat so that unit I migrated could be reused and 
shared amongst other distributions at that time as well being more 
likely to be accepted upstreams ( of those atleast I was in contact with 
) only wanted to maintain a single unit file but cross distribution 
compatibility and the importance of it is something you dont seem to be 
capable of grasping since the only use cases that matters is the one 
that is specific and relevant to you.


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