Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Jóhann B . Guðmundsson]

On 30.4.2022 07:53, Jóhann B. Guðmundsson wrote:

On 30.4.2022 05:08, Andrei Borzenkov wrote:

On 28.04.2022 10:54, Lennart Poettering wrote:

* systemd-boot is an additional bootloader, rather than replacing
   an existing one, thus increasing the attack surface.

Hmm, what? "additional bootloader"? Are they suggesting you use grub
to start sd-boot? I mean, you certainly could do that, but the only
people I know who do that do that to patch around the gatekeeping that
the shim people are doing. Technically the boot chain should either be
[firmware → sd-boot → kernel] or [firmware → shim → sd-boot → kernel]
(if you buy into the shim thing), and nothing else.


I guess "additional bootloader" in this context means that distribution
cannot use sd-boot as the only bootloader for obvious reason - it is EFI
only. So distribution would need to keep currently used bootloader
anyway.



Distributions most certainly can become efi only if they chose to do 
so, there nothing technical that stands in that way.




If current bootloader already works on platforms supported by
distribution, what is gained by adding yet another one?


Freedom of *choice*

If the distribution allows users the freedom to choose from a set of 
components that the OS "made of" or runs, to fit the user use cases or 
has targeted use cases ( which bootloaders such as syslinux, u-boot, 
redboot etc. are aimed at ) then drawing the line at bootloaders makes 
no sense.*

*

If the distribution does not allow users the freedom to choose, then 
it makes no sense to support multiple variants of components that 
provide same/similar function in the distribution.*

*



On that note if you take the bug report [1] that has been cited in this 
thread then it's quite evident that Debian is not about the freedom of 
choice.


"We do not consider it valid to have a choice of boot loaders"

which immediately excludes ca 20+ Linux/(F)OSS boot loader projects and 
thus**discriminates against the person or group of persons behind those 
projects and even the person trying to contribute to Debian itself


"Hi

I'm rescinding this request. I've got a working prototype, but I don't 
know where this would go."



The distribution is not even about freedom of information, which 
prevents individuals from having the ability to seek and receive and 
impart information effectively. ( to understand the how and thus the why 
the conclusion was reached which for in this particular case *all* 
bootloaders projects could look at the dialog, learn from it and fix 
anything if it affected them or correct any misunderstanding that might 
be happening. )



"> Is this discussion public? Can you share it?

We unfortunately do not have a written record of it."

...


JBG

Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Jóhann B . Guðmundsson]

On 30.4.2022 05:08, Andrei Borzenkov wrote:

On 28.04.2022 10:54, Lennart Poettering wrote:

* systemd-boot is an additional bootloader, rather than replacing
   an existing one, thus increasing the attack surface.

Hmm, what? "additional bootloader"? Are they suggesting you use grub
to start sd-boot? I mean, you certainly could do that, but the only
people I know who do that do that to patch around the gatekeeping that
the shim people are doing. Technically the boot chain should either be
[firmware → sd-boot → kernel] or [firmware → shim → sd-boot → kernel]
(if you buy into the shim thing), and nothing else.


I guess "additional bootloader" in this context means that distribution
cannot use sd-boot as the only bootloader for obvious reason - it is EFI
only. So distribution would need to keep currently used bootloader
anyway.



Distributions most certainly can become efi only if they chose to do so, 
there nothing technical that stands in that way.




If current bootloader already works on platforms supported by
distribution, what is gained by adding yet another one?


Freedom of *choice*

If the distribution allows users the freedom to choose from a set of 
components that the OS "made of" or runs, to fit the user use cases or 
has targeted use cases ( which bootloaders such as syslinux, u-boot, 
redboot etc. are aimed at ) then drawing the line at bootloaders makes 
no sense.*

*

If the distribution does not allow users the freedom to choose, then it 
makes no sense to support multiple variants of components that provide 
same/similar function in the distribution.*

*


JBG

Re: [systemd-devel] Static IP address on wandering Wi-Fi client

[Jóhann B . Guðmundsson]

Hi Marcel

On 6/19/19 5:14 AM, Marcel Holtmann wrote:

Hi Johann,


And frankly IP configuration needs to move into the network technology daemons 
like iwd for example.

What's the argument here for that reasoning as in why not consolidate all 
network configuration ( ethernet/wifi/vrrp/vpn's etc.. )  to a single place ( 
networkd )?



Why do you want to keep the network configuration and management space 
fragmented ( as opposed to consolidated ) ?

because that is what the standards are doing. WiFi for example can transport 
the IP address inline. You just need to confirm it with DHCP later. It is how 
the standards are written that you want to really move DHCP one level down. The 
same applies to cellular connections where all the IP level configuration comes 
via the cellular network and not DHCP.



I see that's what the standard specifies but why not merge IWD/EAD with 
systemd ( systemd-wirelessd/systemd-etherauthd and or tightly integrate 
it with networkd )?


What are the benefits you see keeping these as separated components as 
opposed to be part of the service management framework for consolidated 
core/baseOS


The IWD/EAD are Linux only projects right ( as in it's not going to be 
replacing wpa supplicant on other *nix like for example the BSD stack )?


Regards

    Jóhann B.

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

Re: [systemd-devel] Static IP address on wandering Wi-Fi client

[Jóhann B . Guðmundsson]

Hi

On 6/17/19 2:28 PM, Marcel Holtmann wrote:

And frankly IP configuration needs to move into the network technology daemons 
like iwd for example.


What's the argument here for that reasoning as in why not consolidate 
all network configuration ( ethernet/wifi/vrrp/vpn's etc.. ) to a single 
place ( networkd )?



Why do you want to keep the network configuration and management space 
fragmented ( as opposed to consolidated ) ?



Regards

Jóhann B.

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

Re: [systemd-devel] Static IP address on wandering Wi-Fi client

[Jóhann B . Guðmundsson]

Hi

On 6/13/19 2:44 PM, Bruce A. Johnson wrote:

We recently decided to add a Wi-Fi interface as an
option to the Ethernet interface, and it was easy enough to set up
wpa_supplicant to handle connecting the lower layer, after which
systemd-networkd uses the .network file to bring up IP, either using
DHCP or a static IP address.



If you have not yet you should have a look at IWD [1][2][3] before 
settling on wpa_suppplicant for your product.


Regards

 Jóhann B.

1. https://www.youtube.com/watch?v=QIqT2obSPDk

2. https://lists.01.org/pipermail/iwd/

3. https://git.kernel.org/pub/scm/network/wireless/iwd.git/about/

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

Re: [systemd-devel] How to speed up detection of emmc partition and mount the filesystem

[Jóhann B . Guðmundsson]

On 2/4/19 7:22 PM, Petr wrote:


Hello,

I have custom linux on embedded machine generated with Buildroot 
using  emmc drive which contains  root filesystem on /dev/mmcblk0p2 
and application data on  /dev/mmcblk0p4. The root fileystem is mounted 
pretty quickly, but the application data are mounted about 1.7s after 
systemd starts, the main reason is that the mmcbl0p4 is found by 
systemd after 1.4s. As a workaround I created service that is executed 
right after the local-fs-pre.target which execute "mount 
/dev/mmcblk0p4 /app" and that works, but I would like to know if there 
is correct way how to tell systemd that I want to mount the root fs 
and application fs sooner than everything else (I believe that what I 
want is to tell systemd to mount /dev/mmcblk0p4 without waiting for 
udev to find /dev/mmcblk0p4 as new device and start auto mount). 



Hmm... your solution could be a simple type mount unit which is ordered 
before the local-fs-pre.target but maybe not.


+ there are two type of embedded paths in this world those that are 
super tiny resource constrained and those that are not.


Former you dont use systemd for but instead some linux micro platform 
usually tied to or associated with internet of terror devices ( IoT ) 
like Soletta project, the latter you do use systemd for but only after 
systemd has been put on a diet so you will need to provide proper 
context here as in what that custom embedded devices does or is trying 
to do and why you need to shave those 1.4s off, what's the problem you 
are trying to solve with it?


JBG



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

Re: [systemd-devel] Collect logs over serial

[Jóhann B . Guðmundsson]

On 1/31/19 4:34 PM, Paul Menzel wrote:


numbered differently



You can try to do this via tty symlinked udev rule, something along the 
lines of


# /etc/udev/rules.d/99-consistent-serial.rules

# Generic sample ( replace $FOO with something relevant to your 
environment )


SUBSYSTEM=="tty", KERNEL=="tty$FOO", SYMLINK+="ttySLAB0", 
TAG+="systemd", ENV{SYSTEMD_WANTS}+="tty-logger.service"


# Vendir spesific, ( replace idVendor,idProduct,serial for with 
something relevant to your environment


SUBSYSTEM=="tty", ATTRS{idVendor}=="VI123", ATTRS{idProduct}=="IDP123", 
ATTRS{serial}=="12345", SYMLINK+="ttySLAB0" TAG+="systemd", 
ENV{SYSTEMD_WANTS}+="tty-logger.service"


Remove any [Install] section from the tty-logger type service unit.

You might not even need the type service unit ( omitt TAG+="systemd", 
ENV{SYSTEMD_WANTS}+="tty-logger.service" ) if you create a journal 
snippet along these lines...


/etc/systemd/journald.conf.d/ttyslab0.conf

[Journal]
ForwardToConsole=yes
TTYPath=/dev/ttySLAB0
MaxLevelConsole=

Regards

    JBG

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

[systemd-devel] Mkosi and downstream release cycles and their support

[Jóhann B . Guðmundsson]

Greetings


Not sure if this is the right place for mkosi and casync discussions 
probably better create seperated mailing list for both of these 
components ( lates issue against mkosi seems to be a user problem not a 
bug ).


Anyway we have had two bugs reported against mkosi today one of which is 
requesting a new release of mkosi so the Arch community can update and 
create images with the latest Fedora releases and another one that an 
Ubuntu user is trying to create image of an older Ubuntu release which 
does not seem to have properly supported systemd ( which arguably simply 
is unsupported but then there needs to be an error msg to the user )


The Arch related bug/request indicates that the release cycle of mkosi 
needs to be tied to the release cycle of atleast every major 
distribution ( Arch,Fedora,Debian,OpenSuse ) however this will not 
scale, let alone when *every* distribution that ships systemd/mkosi will 
ask to be included, the code most certainly will become un-maintainable 
and quite ugly, quite fast.


The latter requires some kind of policy regarding obsolete of 
distribution ( noticed that few EOL fedora releases seem to be supported 
in the code ) which arguably should never be handled upstream let alone 
hard coded ( arguably upstream should just support latest stable + next 
release )


Cant these whole which distro is supported and on which release be put 
in a file to be read by mkosi,then that file can be update/maintained by 
downstream without having to wait for a new release of mkosi ( and 
downstream can decide that for themselves and deal with those support 
questions and matter ).


Another architectual thing ( and this might be an oversight on my part 
but ) how does mkosi.extra,mkosi.postinst scale along with corresponding 
mkosi.$distribution file?


Does one have to create mkosi.$distribution, mkosi.extra.$distribution 
directory, mkosi.postinst.$distribution for upstreams to deal with 
fragmented distribution mess downstream ( /etc/sysconfig/ red hat ism, 
different package names,  cert location, the all needless deviation that 
resides downstream )


How has this been thought through ( seperate directory's, git repo for 
each distro or what? )


JBG

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

Re: [systemd-devel] taking time off

[Jóhann B . Guðmundsson]

On 1/15/19 8:58 PM, Michael Biebl wrote:

What's going on is just too stupid/crazy.



This begs the question what you consider is too stupid/crazy?

Is it something here upstream ( which could be improved upon )?

Or is it something ( political? ) downstream in Debian?

Or both?

JBG

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

Re: [systemd-devel] RFC: idea for a pstore systemd service

[Jóhann B . Guðmundsson]

On 1/15/19 6:49 PM, Lennart Poettering wrote:

On Di, 15.01.19 11:23, Eric DeVolder (eric.devol...@oracle.com) wrote:


Systemd-devel,

Below is a write-up I've done to explain a new service for archiving pstore
contents. I've attached the pstore.service files
(/lib/systemd/system/pstore.service and bin/pstore-tool). These are trivial
right now, but easy to build upon if periodic, rather than just on-boot,
examination of the pstore is desirable.

If you look at the TODO list in our git tree, you'll find that
importing and flushing pstore has been a long-time TODO list item for
us.


Hmm does it need to be another full blown coredump?

Looking at his script this should suffice more or less for what he was 
trying to achive no?


Create the tempfile pstore.conf with the following content

d /var/lib/pstore 0755 root root -

and place that file in /etc/tmpfiles.d/

Then create an path type unit - pstore.path with the following content

[Unit]
Description=Monitor the pstore directory for files.
Documentation=https://www.kernel.org/doc/Documentation/ABI/testing/pstore

[Path]
PathModified=/sys/fs/pstore/

And place that file in the /etc/systemd/system directory

Then create type service unit pstore.service with the following content

[Unit]
Description=Move pstore files to persistant storage
Documentation=https://www.kernel.org/doc/Documentation/ABI/testing/pstore

[Service]
ExecStart=/bin/bash -c '/usr/bin/mv -t /var/lib/pstore /sys/fs/pstore/*'
Restart=on-success

And place that file in the /etc/systemd/system directory

Then run systemctl daemon-reload and see if this suffices.

Admins or whomever can then just do the cat to dmesg vodoo on the files 
in /var/lib/pstore if and then when they need it


JBG

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

Re: [systemd-devel] Bugfix release(s)

[Jóhann B . Guðmundsson]

On 1/14/19 3:48 PM, Lennart Poettering wrote:


On Mo, 14.01.19 08:43, Dave Reisner (d...@falconindy.com) wrote:


On Mon, Jan 14, 2019 at 10:59:06AM +0100, Jan Synacek wrote:

Hi,

since v240 didn't go too well, I would like to suggest that the next one
(preferably two) release(s) are bugfix only. Please, consider it.

systemd needs better release hygiene, not just a smattering of bugfix
releases. As a rolling release distro, we regularly find release-day
blockers. That's bad for everyone. v240 was particularly bad as 6 months
had elapsed since v239 (and over 3100 commits). That's the longest
timespan and most commits in any systemd release in its nearly 9 year
history.

Well, that sounds as if you want to volunteer as release engineer?;-)

Thing is, we are understaffed. I too have a wishlist of things I'd
like to see done, but with only two paid full-time upstream engineers
there's only so much we can do.



Interesting what has happened to the rest?

Sometimes helps also just to reach out if things are getting to 
understaffed/overwhelmed.


I'm pretty sure that those of us that partook in this journey from the 
get go are still here in one form or another.





If you (or anyone else in the community) would like to step up and
maybe take a position of release engineer, working towards a clearer
release cadence I think everybody would love you for that! I know I
certainly would.

But additional work is not going to be done without anyone doing it.



I would not mind partaking in such collaborated effort and at the same 
time suggest that systemd adapts the upstream kernel release model and 
ties it's upstream release cycle as close to the upstream kernel 
releases as in one major release per kernel's development cycle release 
no later then .rc7 with some middle ground fit's the project to quiet 
down for that release.


With a long term goal here for the linux ecosystem being able to reach a 
state in which every component that makes up the core/baseOS image ( 
getting system to boot and run ) and run on for whatever purpose can be 
released as an single updated image for downstream to consume as an 
update for their devices/distros and what not thou others opinions might 
differ in that regard.


JBG

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

Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[Jóhann B . Guðmundsson]

On 12/02/2016 12:28 PM, Simon McVittie wrote:


Does this mean your user is trying to be physically present in two places
at the same time? How is this a useful thing to do?:-)


Clones are very useful things to have.

You just sit a drink a pina colada in hut in bora bora while they do all 
the hard work ;)


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

Re: [systemd-devel] Fedora 25, cgroups V2 and systemd roadmap

[Jóhann B . Guðmundsson]

On 10/10/2016 11:31 AM, Kevin Wilson wrote:


Hello, systemd developers,
So we have now 3 V2 cgroups controller in the kernel (pids, memory and io).
The CPU controller as of now is not merged in and is available only in
an out of tree git repo (due to some debate over
it with kernel scheduler developers). Not sure that it will be merged
in the next 2 months.

Fedora 25 is to be released in a month and a half, on 15 of November.
https://fedoraproject.org/wiki/Releases/25/Schedule
My questions are:
what are the intentions regarding using cgroup v2 in systemd  in F25
as the default instead of using cgroup V1?
Is the absence of  the CPU controller is a reason for not having
cgroup V2 as a default in F25 ? and if so, why ?


Future and direction of systemd in Fedora should be discussed on the 
fedora development list.


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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 02:47 PM, Greg KH wrote:


In the meantime, to object to other developers doing work on
systemd to test out these changes seems very odd, who are you, or me, to
tell someone else what they can or can not do with their project?


Interesting philosophical question as to who owns the project Lennart? 
Those that contributed lines to it and if so do those contributors just 
"own" their lines ( do I own my contributed lines in the project and 
have a saying on how they are used , I dont think so ) in the codebase? 
is it the community and users surrounding it ( since without it would be 
meaningless) ? who? Questions in which people can and probably would 
debate about to death and beyond for decades.


+ This is about consistency as in about Lennart and others drawing the 
line of having code accepted upstream *before* being taken advantage of, 
used and merged into the project.
An policy I myself whole heartily agree with but at the same time they 
themselves are not following that rule which makes that policy the whole 
definition of hypocrisy does it not?


If the line has been raised from having to be accepted upstream first to 
being *preferred* being accepted upstream first than that's ok, no 
longer hypocrisy and inline with my original mail, contributors and 
downstream expectation adjusted accordingly which I would assume would 
be aligned with the kdbus experience in which years was spent in having 
that committed into the upstream kernel, integration was made into 
systemd and elsewhere, downstream *encourage* to pick it up and begin 
testing it [1] with the added load and changes ( implementing/reverting 
) in contributed/paid time that costed contributors downstream. An 
costly experience that would have never come to pass if previous rule 
that was drawed in the sand had been followed to the letter.


I personally recommend the project should stick with the original line 
drew in the sand, for the master branch and all the "experimental" stuff 
which may or may not come to pass, be kept in it's own experimental 
branch which would be the best of the both worlds I would think. 
Downstream that want stability get what they want and are less likely to 
experience any sudden *surprises* and those that want the experimental 
stuff for whatever reason like testing get what they want.



JBG

1. 
https://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 12:53 PM, Greg KH wrote:


On Tue, Aug 16, 2016 at 12:51:12PM +, Jóhann B. Guðmundsson wrote:

>On 08/16/2016 12:34 PM, Greg KH wrote:
>

> >But agreement is usually the best way to work things out, don't you
> >think?  Isn't it better than the traditional way a company works (a
> >project manager says "this has to be merged!")?

>
>Agreed mutual agreement is the best course of action always but sometimes
>drastic measures will need to be taken to break status quo.

Which is what happens when needed.  We've been doing this for a long
time now, you would think that people would trust us by now...


Less to do with trust more to do with the fact If that process was 
working, Tejun Heo changes would have been merged ( or some mutual 
agreement reached on the way forward ) and we would not be having this 
discussion here in the first place.


I would be living in my black and white world in which everything is 
dictated and dominated by cause and effect equal and opposite reaction, 
the black and white, the zeros and ones and you would be living in your 
"gray area" plane of existence hunting pokemons or doing whatever floats 
your boat;)


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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 12:51 PM, Greg KH wrote:

On Tue, Aug 16, 2016 at 12:47:16PM +, Jóhann B. Guðmundsson wrote:


Irrelevant.

No, not at all, I'm just really confused as to what systemd changes are
required to get wireguard working properly with it?


Think of it like native integration with .network files and the likes as 
in the interface would be configured ||with it as opposed to be using 
wireguards own configuration file but as I said it's irrelevant since 
how and to what extent is subjected to changes once Susant and Tom have 
had a chance to review such work but before any such work can be started 
Jason needs to submit the relevant bits to be included in the kernel 
first which afaik he has still not done.


No biscuits and marmalade and until the hottest (vpn) kid on the block 
has been merged upstream.


JBG

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 12:34 PM, Greg KH wrote:


But agreement is usually the best way to work things out, don't you
think?  Isn't it better than the traditional way a company works (a
project manager says "this has to be merged!")?


Agreed mutual agreement is the best course of action always but 
sometimes drastic measures will need to be taken to break status quo.


Did not the filesystem maintainers all get locked in a room until they 
could agree on the way forward in which they where let out of the room 
again and out came btrfs ;)


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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 12:31 PM, Greg KH wrote:

On Tue, Aug 16, 2016 at 12:25:47PM +, Jóhann B. Guðmundsson wrote:


On 08/16/2016 11:28 AM, Greg KH wrote:

On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote:


Such as what specifically?


Are you pretending you are going to be reviewing this now?


  Do other VPNs require changes to systemd in
some way?


Irrelevant.




Why are you so fixated on this since his stance is arguably the correct one
on refusing this in the first place *until* this has been implemented in the
upstream kernel which arguably and should have been done in relation with
cgroup v2 until that got sorted out.

Who is "his"?


Tom if you must know but that view was shared with Kay and Lennart at 
one point.





Are you against the policy of upstreaming first?

The world is not black and white :)


Aha like saving the planet has anything to do with saving the planet but 
you have answered what I asked.


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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 12:13 PM, Greg KH wrote:

On Tue, Aug 16, 2016 at 11:23:03AM +, Jóhann B. Guðmundsson wrote:

Why cant the kernel community figure this out and solve this upstream first
since it's quite obvious from the threads that Tejun Heo linked to in that pull
request that this is a political issue not a technical one.

Surely Linus and his so called lieutenants can step in and break political
status quo like that.

That makes no sense at all, sorry.  Work with the upstream developers to
get this resolved, that's all that anyone can do here.


So each maintainer can prevent changeset from being merged if affect the 
area he ( currently ) maintains the kernel.


That's interesting and begs the question how much time and energy the 
kernel community spend in resolving matters that stem from "opinions" 
and people stubbornness?


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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 11:28 AM, Greg KH wrote:

On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote:


On 08/16/2016 10:44 AM, Greg KH wrote:

On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote:

Recent case in point is the that the wireguard maintainer was/is interested
seeing it property integrated into systemd. Anywork related to that could not
be started *until* he had his stuff merged in the upstream kernel however now
anyone can have anything not upstreamed implemented in systemd.

Wait, what needs to be added to systemd to get wireguard "working"
properly?  It's just like any other network VPN service, what makes it
special (well, becides the very coolness of it of course...)

Were there patches that were rejected?  Any pointers to them?

The patches have not been written yet because the systemd developer
mentioned he would not accept it until this was merged upstream.

Again, what type of patches to systemd are needed for wireguard?



For example changes to networkd configuration files.

Why are you so fixated on this since his stance is arguably the correct 
one on refusing this in the first place *until* this has been 
implemented in the upstream kernel which arguably and should have been 
done in relation with cgroup v2 until that got sorted out.


Are you against the policy of upstreaming first?

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 10:42 AM, Greg KH wrote:


As long as this new code doesn't break things for users without those
kernel patches, why would you object?  Are you having to maintain these
new features for some reason?


No but I eventually might have to deal with the fallout from such approach.

Why cant the kernel community figure this out and solve this upstream 
first since it's quite obvious from the threads that Tejun Heo linked to 
in that pull request that this is a political issue not a technical one.


Surely Linus and his so called lieutenants can step in and break 
political status quo like that.


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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 10:27 AM, Lennart Poettering wrote:


On Tue, 16.08.16 10:11, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:


Yes kdbus is a good example why this should  not be done.

Why not just have an experimental repository for out of tree, un-merged
stuff upstream and those that want to use/rely/test that stuff can build and
run it downstream?

Because we want this stuff in the hands of people. In fact, we are
interested into seeing the matching kernel patch in Fedora kernels
too, in order to make sure this gets more presence.


I have to ask to what end?

This was not accepted upstream so is the plan here to expose this to 
larger use base, have downstream make the necessary changes to somehow 
pressure the upstream kernel community to accept this?


If Red Hat wants the Fedora community to implement this "for testing and 
exposure" for their clients and business partners they should do so via 
copr repo along with a kernel that contains this patch and any exposed 
bugs wont get fixed in the kernel community since this has not been 
accepted right + the first one that get's bitten by any regression this 
might introduced would be the Arch community and probably CoreOS/Google 
long before the Fedora community ( Fedora is not leading anything 
anymore other than it's community members in circles ) who are running 
like headless chickens now after the failed implementation of Red Hat 
product ( read as the products/editions/WG's  ) which has made the 
distribution worse off than it was when it was "generic" but there is an 
effort now making Fedora generic again called "modular" so it can be 
everything to anyone just like it was before and that circle will 
complete itself.




And cgroupsv2 isn't just some entirely random thing: it fixes major
bugs for us, and is at the core what systemd does.


Which arguably is even more of a reason why un-merged upstream changes 
should not be implemented since fluctuating changes to such a core 
implementation in systemd can cause serious regression for downstream(s).


What's the long term plan here if the kernel community never accepts this?

What are you planning to do then and how do you expect downstreams to 
handle that?


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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 10:44 AM, Greg KH wrote:

On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote:

Recent case in point is the that the wireguard maintainer was/is interested
seeing it property integrated into systemd. Anywork related to that could not
be started *until* he had his stuff merged in the upstream kernel however now
anyone can have anything not upstreamed implemented in systemd.

Wait, what needs to be added to systemd to get wireguard "working"
properly?  It's just like any other network VPN service, what makes it
special (well, becides the very coolness of it of course...)

Were there patches that were rejected?  Any pointers to them?


The patches have not been written yet because the systemd developer 
mentioned he would not accept it until this was merged upstream.


Which is a perfectly legit perspective.

JBG

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 09:06 AM, Lennart Poettering wrote:

On Mon, 15.08.16 16:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
The world isn't just black and white, you know.


That depends entirely on ones perception of the world does it not?

I'm interesting to hear when it is not but such philosophical discussion 
are probably best served over a beer.


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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

On 08/16/2016 09:04 AM, Lennart Poettering wrote:


On Mon, 15.08.16 10:53, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

Johann, what you are posting here is really not helpful in any
way.


It's helpful in that way of letting people know that you have chosen to 
deviating from upstream first is policy so people can submit work which 
has not been accepted in other upstreams.


Recent case in point is the that the wireguard maintainer was/is 
interested seeing it property integrated into systemd. Anywork related 
to that could not be started *until* he had his stuff merged in the 
upstream kernel however now anyone can have anything not upstreamed 
implemented in systemd.





Yes, we generally want a clear upstreaming perspective for kernel
changes we support. But we have merged support for stuff that wasn't
upstream yet before (most prominently: kdbus), and we will continue to
do so in future. Yes, it would be great if cgroupvs2 would be fully
merged in the upstream kernel, but given that in most parts it
actually is and it provides systemd with major benefits to its core, I
think it's fine to merge the support for cgroupsv2 already.



Yes kdbus is a good example why this should  not be done.

Why not just have an experimental repository for out of tree, un-merged 
stuff upstream and those that want to use/rely/test that stuff can build 
and run it downstream?


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

[systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Jóhann B . Guðmundsson]

Just a heads up based on the merge  of [1] systemd no longer requires 
features to have been accepted in the upstream kernel before merging it.


Adjust you expectation accordingly for submission and potential 
downstream breakage for type units in which upstream might have decided 
to take advantages of such merged features in systemd.


JBG

1. https://github.com/systemd/systemd/pull/3905

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

Re: [systemd-devel] firmware update check script

[Jóhann B . Guðmundsson]

On 08/04/2016 07:45 AM, Stéphane ANCELOT wrote:


You are right, but that's only  systemd that is incompatible with this feature 
(and some more).


Actually all initsystems are incompatible with this.


As some people and some articles I have read on the web, it is time for myself 
switching my system to a professional initscript service.


If you have not switched your system to an systemd based distribution 
now would be the time.


JBG


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

Re: [systemd-devel] Standardizing names for graphical session units

[Jóhann B . Guðmundsson]

># gnome-user-graphical.target
>
>[Unit]
>Description=User systemd services for graphical session
>StopWhenUnneeded=yes

So this is just another name for "my"
gnome.target/gnome-session.target. As I said I'm not too fussed about
how we name those, we should just decide about some convention.


Right.




>In your script you had an conflicting naming scheme (
>gnome.target/graphical.target ) and a colliding one ( graphical.target with
>systemd default and potentially other DE's as well ) if multiple desktop
>environments where installed.

I don't see a conflict. These are all per-user units, so if user A
runs kde-session.target and user B runs gnome-session.target that's
fine -- the two user systemd instances don't even know about each
other.


It's more about people will be have hard time distinguish between two or 
more type units with the same name but serve two different purposes.


This would work if an new type unit would be introduced which could be 
called .session or .user so you would end up with gnome.session or 
gnome.user instead of gnome.target for example or gnome.service etc.


It might be an option to introduce a new type unit(s) since the existing 
type units might not be the right way to handle this.



>And you also might need to add something like an Alias ( like for example
>"Alias=user-graphical.target" ) directive to the DE-user-graphical.target
>unit so that someapp.service can be made PartOf an generic directive
>(PartOf=user-graphical.target) to make it DE agnostic ( should it be
>required to be so ) if it's not DE specific. ( if you follow me here ).

I do follow. However, there is no such thing as a "runtime alias" for
units, TTBOMK. There is Alias= in the [Install] section, but this
cannot really be used for this purpose -- we don't want to change
the /usr/lib/systemd/user/user-graphical.target symlink every time
that we start a user session in a DM.


I was just using it as an example since you have the same problem trying 
to describe "generic" ordering/requirement/dependency in type units.


One way to solve them is with type target units as you proposed ( 
user-graphical.target could serve that purpose ) but back in the day 
Lennart was against introducing generic type targets like 
webserver.target, database.target etc which would have simplified things 
quite a bit in various type service for applications that needed for 
example be ordered either after or before like After=webserver.target vs 
having to define all of them in the existence 
Apache,Nginx,Lighttpd,Monkey,Cherokee,Hiawatha etc. So I just 
automatically dismissed that as a solution since I assumed he would be 
consistent and reject such proposals/ideas.


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

Re: [systemd-devel] Standardizing names for graphical session units

[Jóhann B . Guðmundsson]

On 07/06/2016 02:34 PM, Martin Pitt wrote:


This /usr/lib/systemd/user/graphical.target (and only that)*does*
belong in to systemd, as it cannot sensibly be in any
gnome-session/mate-session/kde-session/etc. package -- it's a shared
resource/synchronization point between all of those. Having a unit
structure which actually works and is reasonably easy to extend and
maintain is AFAICS the main blocker why systemd isn't being used for
desktop environments at all yet.


I think we are talking somewhat in mixed direction here.

What I'm ( poorly ) trying to say is that you will need to make a clear 
distinction of naming on the type units for the desktop environment and 
the type units for the desktop environment user and potentially other 
existing type units on the system to avoid confusions and conflicting 
naming scheme, since Desktop Environments will need to have their own 
targets so based on my comments on this and for Gnome ( on Fedora ) and 
on the type units you are creating in your script ( that all have to 
reside in ~/.config/systemd/user/ directory for all the desktop 
environment user type units right ) so this would become something along 
the lines of


# gnome.target

[Unit]
Description=Gnome Desktop Environment
Documentation=https://wiki.gnome.org/
Requires=multi-user.target
Wants=gdm.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target gdm.service
AllowIsolate=yes

# gdm.service

[Unit]
Description=GNOME Display Manager
Conflicts=getty@tty1.service
After=getty@tty1.service
Conflicts=plymouth-quit.service
After=plymouth-quit.service
After=rc-local.service plymouth-start.service systemd-user-sessions.service
OnFailure=plymouth-quit.service

[Service]
ExecStart=/usr/sbin/gdm
KillMode=mixed
Restart=always
IgnoreSIGPIPE=no
BusName=org.gnome.DisplayManager
StandardOutput=syslog
StandardError=inherit
EnvironmentFile=-/etc/locale.conf

# gnome-user-graphical.target

[Unit]
Description=User systemd services for graphical session
StopWhenUnneeded=yes

# gnome-user.target
[Unit]
Description=User systemd services for GNOME graphical session
BindsTo=gnome-user-graphical.target  gnome-user-session.service

# gnome-user-session.service
[Unit]
Description=gnome-user-session leader
PartOf=gnome-user-graphical.target

[Service]
ExecStart=/bin/sleep infinity

# someapp.service
[Unit]
Description=example graphical app
PartOf=gnome-user-graphical.target

[Service]
ExecStart=/bin/sleep infinity

...

This will allow for

# DE units
kde.target
kdm.service
xfce.target
xdm.service


DE user type units
kdm-user-graphical.target
kdm-user.target
kdm-user-session.service
xfce-user-graphical.target
xfce-user.target
xfce-user-session.service
etc..

In your script you had an conflicting naming scheme ( 
gnome.target/graphical.target ) and a colliding one ( graphical.target 
with systemd default and potentially other DE's as well ) if multiple 
desktop environments where installed.


And you also might need to add something like an Alias ( like for 
example "Alias=user-graphical.target" ) directive to the 
DE-user-graphical.target unit so that someapp.service can be made PartOf 
an generic directive (PartOf=user-graphical.target) to make it DE 
agnostic ( should it be required to be so ) if it's not DE specific. ( 
if you follow me here ).


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

Re: [systemd-devel] Standardizing names for graphical session units

[Jóhann B . Guðmundsson]

On 07/06/2016 12:51 PM, Jan Alexander Steffens wrote:
On Wed, Jul 6, 2016 at 2:21 PM Jóhann B. Guðmundsson 
<johan...@gmail.com <mailto:johan...@gmail.com>> wrote:



It's questionable if such application should reside in upstream
systemd since arguably systemd should have never created the
graphical.target to begin with ( if it had not we probably would
not be having this discussion since desktop environment targets
would have been created instead ).



What do you mean? There is no user-level graphical.target in systemd 
(yet), and this discussion has nothing to do with the system-level 
graphical.target.


Martin is proposing changes to and dependency's on the graphical.target 
trying to make it act as the abstraction layer ( since there does not 
exist a single DM solution that serves all DE properly ) which will 
never work since each desktop environment will need it's own target 
which can be isolated to so applications/administrators and end users 
can switch desktop environments ( by simply switching/isolating to 
another target ) if they have installed multiple DEs to be able to 
effectively handle the usecase that Colin pointed out ( classic use case 
for that are labs in university's ) .


If you only have a single DE environment installed you could just make 
that DE the default target of the installment and skip entirely the 
graphical target if everything gets correctly implemented ( in effect 
obsoleted it ) however if you try to use a DM that belongs to an single 
desktop environment ( as opposed to one DM to rule them all ) with 
multiple desktop environments you will always end up with a mess on your 
hand.


In anycase none of the desktop environment targets should ever be 
shipped with systemd upstream and depend on graphical.target but only be 
as a part of their relevant desktop environment, shipped with it and 
depend on it's own target otherwise systemd as an core/baseOS component 
is being (mis)used to achieved consolidation in areas which are outside 
it's scope.


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

Re: [systemd-devel] Standardizing names for graphical session units

[Jóhann B . Guðmundsson]

On 07/04/2016 08:01 PM, Martin Pitt wrote:


Feedback appreciated!


Shipping an predefined desktop units arguably does not belong upstream 
since it's just catering to one ( desktop ) out of three ( 
embedded/server/desktop) target user base.  It might result in other two 
target user base having to patch things out in the environment.


Why would you call it graphical-<$DE>.slice as opposed to simply 
<$DE>.slice which is part of the <$DE>.target and graphical target is 
link to that <$DE>.target  ( if shipped upstream it needs to be generic 
enough to cater whatever is out there right )


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

Re: [systemd-devel] systemd.conf early-bird tickets, cfp and workshops

[Jóhann B . Guðmundsson]

On 06/27/2016 02:36 PM, Chris Kühl wrote:


Workshops:

A new addition to this year's conference is the workshop day. The goal
of this day is to offer hands-on training sessions to those who want
to learn more about systemd. It's intended that these trainings be
conducted by systemd community members. Proposals for workshops can be
submitted at https://cfp.systemd.io

If you have questions about workshops please contact us at i...@systemd.io

Or you can just be replied to here since you advertise 300 euro 
participation fee for workshop schedule that a) does not exist and b) is 
not part of the professional package ( read as corporate sponsored 
individuals since we do have quite few that would be considered 
professionals in the community, where this might be a value add to ) is 
expected to be conducted by systemd community members for systemd 
community members ( since they would also have to pay 300 euro fee also 
to attend ).


It would be good to know who's the genius behind this idea, ( read sat 
somewhere at an meeting and had the "hey here's an idea let's add 
workshop to the mix, have the community manage it and charge 300 euros 
for it in the process" )  the pricing behind it and where does all that 
money go?


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

Re: [systemd-devel] Can LSBInitScipts specify an dependency on systemd unit?

[Jóhann B . Guðmundsson]

On 06/09/2016 09:02 AM, Ross Lagerwall wrote:


On Thu, Jun 9, 2016 at 9:55 AM, Bao Nguyen  wrote:
With a new enough systemd, you should be able to add a snippet to extend
the initscript like this:
$ cat /etc/systemd/system/my_lsb_service.service.d/local.conf
[Unit]
Requires=systemd_1.service
After=systemd_1.service


That's just silly and introduces another level of administrator headache.

What he's requesting is something that belongs as a feature request in 
sysv or the likes and never should be supported in systemd in any shape 
or form.


If you use systemd write type unit for that not legacy sysv initscript.

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

Re: [systemd-devel] Can LSBInitScipts specify an dependency on systemd unit?

[Jóhann B . Guðmundsson]

On 06/09/2016 08:55 AM, Bao Nguyen wrote:



Can it be declared like that? Can it work as expected if LSB depends 
on systemd service?




Migrate that scripted mess to type units and be done with it.

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

Re: [systemd-devel] question on special configuration case

[Jóhann B . Guðmundsson]

On 06/08/2016 06:51 AM, Hebenstreit, Michael wrote:


Thanks for this and the other suggestions!

So for starters we’ll disable logind and dbus, increase watchdogsec 
and see where the footprint is – before disabling journald if 
necessary in a next step.




You cannot disable journal but you can reduce it and the following 
should give the least amount of logging in all potential scenarios and 
usage ;)


Just create "/etc/systemd/journald.conf.d/10-hpc-tweaks.conf"which contains

[Journal]
Storage=none
MaxLevelConsole=emerg
MaxLevelStore=emerg
MaxLevelSyslog=emerg
MaxLevelKMsg=emerg
MaxLevelConsole=emerg
MaxLevelWall=emerg
TTYPath=/dev/null

Then restart the journal ( systemctl restart systemd-journald )

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

Re: [systemd-devel] question on special configuration case

[Jóhann B . Guðmundsson]

On 06/07/2016 10:17 PM, Hebenstreit, Michael wrote:


I understand this usage model cannot be compared to laptops or web servers. But 
basically you are saying systemd is not usable for our High Performance 
Computing usage case and I might better off by replacing it with sysinitV. I 
was hoping for some simpler solution, but if it's not possible then that's 
life. Will certainly make an interesting topic at HPC conferences :P


I personally would be interesting comparing your legacy sysv init setup 
to an systemd one since systemd is widely deployed on embedded devices 
with minimal build ( systemd, udevd and journald ) where systemd 
footprint and resource usage has been significantly reduced.


Given that I have pretty much crawled in the entire mud bath that makes 
up the core/baseOS layer in Fedora ( which RHEL and it's clone derive 
from ) when I was working on integrating systemd in the distribution I'm 
also interesting how you plan on making a minimal targeted base image 
which installs and uses just what you need from that ( dependency ) mess 
without having to rebuild those components first. ( I would think 
systemd "tweaking" came after you had solved that problem first along 
with rebuilding the kernel if your plan is to use just what you need ).


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

Re: [systemd-devel] question on special configuration case

[Jóhann B . Guðmundsson]

On 06/07/2016 03:13 PM, Hebenstreit, Michael wrote:


  we need to keep the OS of our systems are stripped down to an absolute bare 
minimum.


If you need absolute bare minimum systemd [¹] then you need to 
create/maintain your entire distribution for that ( for example you 
would build systemd so you just with what you need and use systemd's 
built in networkd not NetworkManager, timesyncd not ntp etc, change sshd 
to be socket activate, only install components necessary for the 
application to run, kernel mods so fourth and so on ) .


If you need to perform benchmark on Red Hat and it's derivatives/clones 
then disable this would scew the benchmark output on those would it not?


Can you clarify how dbus-daemon, systemd-journald, systemd-logind, 
systemd-udevd are causing issue/impacting in the above setup some thing 
more than "I dont think we need it hence we want to disable it".


JBG

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

Re: [systemd-devel] Systemd ask-password unable to handle cryptsetup passwords with \0 character inside ?

[Jóhann B . Guðmundsson]

On 06/07/2016 01:26 PM, Lennart Poettering wrote:


Not sure where this really
leaves us.


It leaves people wondering if it fits into bus 1. . .

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

Re: [systemd-devel] systemd network interface names - new twist

[Jóhann B . Guðmundsson]

On 06/02/2016 04:33 PM, JB wrote:




Thanks, that's the plan but in order to buy myself that time, I'd need 
to get this resolved first. 


I'm afraid you wont buy yourself anything since your only option is to 
start immediately to look into applying real-time kernel patches or find 
another distro since F21 is EOL and the only response you get from 
everybody is "upgrade" or "try with latest release"


F22 is on 4.4x kernels F23/F24 is on 4.5.x ( soon to be on 4.6.x ) and 
rawhide on 4.7.x so you need to apply patches to those release or use 
for example CentOS 7.x which comes with the 3.10 kernel


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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Jóhann B . Guðmundsson]

On 05/26/2016 02:38 PM, Lennart Poettering wrote:

>On 05/26/2016 09:36 AM, Lennart Poettering wrote:
>

> >/usr is for the OS vendor really.

>
>Given that it's generally expected and wanted that application developers
>follow the os vendors packaging guideline and rules as possible in
>distribution and many 3rd party repositories reflect that, I have to ask
>what's your reasoning for limit this to OS vendor only?

It's a shared namespace. Distros have enough problems already making
sure that no two packages own the same names for their binaries,
libraries, ... If you now allow multiple unrelated parties to all dump
their own stuff in there, then you can only fail with that.


If 3rd party application providers aren't following the vendor OS 
packaging guidelines well then that OS vendors will have that mess on 
it's hand ( or rather that unfortunate administrator that install said 
application or application stack ) and that pretty much can be said 
about anyone or anything not following upstream or "standards" in 
general so such scenarios are doomed to fail regardless of any effort in 
trying to prevent that .




I think /opt is deeply flawed and not thought to the end, but the one
thing it does get right is that every vendor package gets its own dir
below /opt, thus dealing with the namespacing problems at least a bit.


That's not always the case and it's not guaranteed that 3rd party even 
follows that, some choose to use /srv instead of /opt and some choose to 
place their things anywhere .


If those glorified "holy unix bible" writers in last century could have 
thought ahead, they would have created /usr/vendor at the same time they 
created /usr/local and everyone would have adapted to that already but 
here we are on a new century with file system//hierarchy mess on our 
hand, which hopefully in not to distant future application containers 
will take care of for us since fixing this requires joint collaborated 
effort of ( at least major ) distributions and them implementing it at 
the same time and that's not going to happen anytime soon, if ever since 
some of those distribution hold so deer into their false sense of 
"independence" or deliberately are deviating and forking themselves from 
one another due to "competition".


JBG


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

Re: [systemd-devel] check to see if service is still alive

[Jóhann B . Guðmundsson]

On 05/26/2016 01:15 PM, Lennart Poettering wrote:


On Thu, 26.05.16 14:39, Thomas Güttler (guettl...@thomas-guettler.de) wrote:


>Am 26.05.2016 um 14:35 schrieb Andrei Borzenkov:

> >On Thu, May 26, 2016 at 3:18 PM, Thomas Güttler
> >  wrote:

> >>I want to know if the service is alive,

> >
> >Define "service is alive".

>
>the service is alive if a custom check method has the exit status of 0

That's out of the scope for systemd really. That's monitoring, and I
am not convinced having custom check function support in systemd is
really appropriate, this should be implemented outside of systemd
really.


Administrators usually create type timer units which are bound to 
relevant type service unit and is run on periodic interval and checks if 
the service responses and restarts it if it's not for those use cases 
where the daemon/service is in some limbo state and not responding for 
whatever reason ( that is if they dont have any monitoring system like 
zenoss or nagios etc that does that for them ).


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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Jóhann B . Guðmundsson]

On 05/26/2016 09:44 AM, Frederic Crozat wrote:


I don't know how this software will be shipped, but if it is as a RPM
package, it is best to be installed in /usr/lib/systemd/system.
/etc/systemd/system should be for admins or 3rd parties not using
packages.


/etc is admin only territory and should not be touch by anything other 
than themselves these days so unless the administrators create the type 
unit file themselves nothing should be placing type unit files there 
including 3rd parties not using packages.


Arguably those upstream should not be shipping type unit files, legacy 
sysv initsctipts etc et all and I know for a fact that many upstream 
project outright refuse to play "favorite init system" and dont ship 
init scripts or type unit files with their project since they rejected 
my submission of type units to them based on that principal.


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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Jóhann B . Guðmundsson]

On 05/26/2016 09:36 AM, Lennart Poettering wrote:


/usr is for the OS vendor really.


Given that it's generally expected and wanted that application 
developers follow the os vendors packaging guideline and rules as 
possible in distribution and many 3rd party repositories reflect that, I 
have to ask what's your reasoning for limit this to OS vendor only?


JBG

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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Jóhann B . Guðmundsson]

On 05/26/2016 06:52 AM, Rashmi Ranjan Mohanty wrote:


Just out of curiosity... If /usr itself is there on a separate partition, can 
this issue happen
then or systemd can handle that scenario ?


Systemd can cope with /usr being on separated partition however other 
core/baseOS components might not, so you need to ensure that you boot 
with an initrd that mounts /usr before jumping into the root file system 
and everything on the core/baseOS layer should be fine otherwise things 
might fail silently and go unnoticed or fail spectacularly depending on 
the component(s) in question.


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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Jóhann B . Guðmundsson]

On 05/25/2016 03:22 PM, Lennart Poettering wrote:


On Wed, 25.05.16 10:05, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:




You will always risk ending up with a race condition if you place your type
units outside the official directories.

/etc/systemd/system/*  ( Administrators )
/run/systemd/system/* ( Temporary )
/usr/lib/systemd/system/* ( Vendors )

Arguably the support running/loading type unit files outside the above
directories should be altogether removed or at least a warning issues since
this is bound to create administrative mess ( as was apparent when vendor
did something like that with legacy sys v init ).

I don#t really agree I must say.


It's classic ( sys v ) init brokenness in which vendors placed their 
stuff in opt ( or elsewhere ) which more often than not was a) on 
separated partition b) on separated sub-volume c) on a network drive ( 
nfs and the likes ) then symbolic linked ( through install script ( 
which usually do more harm than good since such scripts assumptions are 
way off with the environment and infrastructure policy's ) to one of the 
classic init.d directories which led to the exactly same racy condition 
( if legacy sysv initscript and or type units depend on something else ) 
and brokenness as he's experiencing here.


What's the use case for placing type unit files outside those 
directories and supporting following symlinks to them?


Why dont you always want to require type unit files to be placed in 
those directories to prevent things like he's experiencing and I 
mentioned above from happening?


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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Jóhann B . Guðmundsson]

You will always risk ending up with a race condition if you place your 
type units outside the official directories.


/etc/systemd/system/*  ( Administrators )
/run/systemd/system/* ( Temporary )
/usr/lib/systemd/system/* ( Vendors )

Arguably the support running/loading type unit files outside the above 
directories should be altogether removed or at least a warning issues 
since this is bound to create administrative mess ( as was apparent when 
vendor did something like that with legacy sys v init ).


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

Re: [systemd-devel] automount nested nfs share

[Jóhann B . Guðmundsson]

Open up a support case with Red Hat since that's what you are paying for.


On 05/04/2016 08:40 AM, Marco Giunta wrote:

Hi at all,
I've a problem with automount features of systemd. I need to mount two 
nfs share in this way:



/srv/nfsnfs-server.example.com:/share1
/srv/nfs/nestednfs-server.example.com:/share2


On my old RHEL6 workstation, I used autofs, but now, with a RHEL7 
workstation, I'd like to use systemd.


I've configure two mount units, and they work like a charm: the nfs 
export are mounted like I guess. Then, I've configured an automount 
unit for '/srv/nfs', and it works, BUT when I 've created an unit to 
automount '/srv/nfs/nested', and started it, immediately '/srv/nfs' 
has been mounted, and I cannot unmount it (device is busy).


If I stop '/srv/nfs/nested' automount service, I can unmount 
'/srv/nfs'. I'm trying to figure out the problem, and I think the 
reason is 'automatic dependencies':


"""
If an automount unit is beneath another mount unit in the file system 
hierarchy, both a requirement and an ordering dependency between both 
units are created automatically.

"""

in fact:

# systemctl list-dependencies srv-nfs-nested.automount
srv-nfs-nested.automount
  -.mount
  srv-nfs.mount


'srv-nfs-nested.automount' depends on 'srv-nfs.mount'. I don't want 
this, I want the 'srv-nfs-nested.automount' depends on 
'srv-nfs.automount', because I don't want to have '/srv/nfs' always 
mounted, I need to mount it on request, I have more then 300 
workstations to configure.


I've tried to change these settings:

DefaultDependencies = false
Requires=srv-nfs.automount -.mount

but it doesn't works, because 'DefaultDependencies' doesn't disable 
all dependencies:


'''
If set to false, this option does not disable all implicit 
dependencies, just non-essential ones.

'''

So, my question is: is there a way to disable implicit dependencies ?? 
Or is there another way to automount nested nfs share with systemd ??


With autofs, I used a configuration like this:

/srv/nfs-fstype=nfs4,rw \
/nfs-server.example.com:/share1 \
/nestednfs-server.example.com:/share2 \
/nested2nfs-server.example.com:/share3

and it works as I guess.

Cheers,
  Marco


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


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

Re: [systemd-devel] centos-ci

[Jóhann B . Guðmundsson]

On 04/12/2016 02:43 PM, Lennart Poettering wrote:

On Tue, 12.04.16 11:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:


Anyone know that centos is not running the latest version(s) of systemd
required for the upstream bug tracker so one has to ask what notification
spam is this
"Can one of the admins verify this patch?"

Daniel is working on adding a CI infrastructure that allows us
building things on a RHEL-based system for each PR. This is work in
progress, and the spamming of the PRs with the mentioned line an
unfortunate mistake.

We have no intention to support upstream systemd on such old RHELs,
but the test systems are hacked enough with never packages to allow us
test things on Red-Hat-based systems.

Right now the CI systems we use are all based on Ubuntu, which is
kinda weird, as most of the systemd core developers actually work for
RH and run Fedora locally... ;-)


I see but It's should not matter which company you work for or which 
distribution upstream developers favor otherwise you end up risking 
bias-ing the product on those favored downstream distribution or the 
(current) employment which is one of the root cause for the existing 
fragmentation in the first place.


And based on your response I have to ask, is someone higher up the Red 
hat ladder yanking your chain and thus the project loosing it's 
independence in the process or has your and other systemd's core 
developers view on the matter being independent changed?


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

[systemd-devel] centos-ci

[Jóhann B . Guðmundsson]

Anyone know that centos is not running the latest version(s) of systemd 
required for the upstream bug tracker so one has to ask what 
notification spam is this

"Can one of the admins verify this patch?"

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

Re: [systemd-devel] udev vs. nscd vs. /var automount

[Jóhann B . Guðmundsson]

On 04/06/2016 09:15 AM, Łukasz Stelmach wrote:

Hi,

I've hit a problem caused by a mix of: automounting + glibc + udev + my
partition layout. Apparently it is impossible to make /var automountable
because udev (which needs to enumerate devices befor mounting them) is
trying to connect to /var/run/nscd/socket (that's actually glibc
code). This attempt does not fail because autofs tells there still is
hope that the path will appear soon but it won't because udev can't tell
the device to mount exists.

I've checked glibc source and it still refers to /var/run/nscd/socket
rather than /run/nscd/socket. As far as I know there is no way to
disable nscd lookups.

Any idead how to cope with it?


Cant you disable nscd it in glibc via configuration options via 
--disable-nscd and or --disable-nscd --enable-build-nscd if you dont 
need/want it?


Then there is this patch [1] which may or may not have been upstreamed 
already...


1. 
https://github.com/OpenMandrivaAssociation/glibc/commit/e251ac2a53eb4a4571b7c7a7fd79e2091478bdc2


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

Re: [systemd-devel] [ANNOUNCE] systemd.conf 2016

[Jóhann B . Guðmundsson]

On 04/05/2016 08:40 AM, Lennart Poettering wrote:

one day of hands-on
training sessions.


Who will be training what exactly?

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

Re: [systemd-devel] systemd efi boot and default entry

[Jóhann B . Guðmundsson]

On 04/01/2016 03:15 PM, Tobias Hunger wrote:

On Fri, Apr 1, 2016 at 4:59 PM, Jóhann B. Guðmundsson
<johan...@gmail.com> wrote:

That makes no sense that an boot is not market completed until it manage to
contact it's update servers but inline with other hacks coreOS is doing in
relation with systemd.

I sense a lot of negativity here:-)

A server needs to provide some set of functionality. Only once that
functionality is available the server has booted successfully.


So if your server has the role of an web server and the web service 
fails to run or is not run ( for example you forgot to enable it, or you 
misconfigured it before rebooting ) or that phone home service failed 
since it could not contact it's home server due to wide variety of 
possible network related issue or was booted into a different boot 
target or due to simple type unit (mis)ordering that would constitute as 
the operating system failing to boot?


I dont follow that logic and with my administrator hat on would never 
want to have my servers rely or depend on such boot completion logic sorry.


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

Re: [systemd-devel] systemd efi boot and default entry

[Jóhann B . Guðmundsson]

On 04/01/2016 03:15 PM, Alex Crawford wrote:

On 04/01, Jóhann B. Guðmundsson wrote:

That makes no sense that an boot is not market completed until it manage
to contact it's update servers but inline with other hacks coreOS is
doing in relation with systemd.

To what hacks, exactly, are you referring?


The environment one [¹]

1. 
https://lists.freedesktop.org/archives/systemd-devel/2015-December/035364.html


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

Re: [systemd-devel] systemd efi boot and default entry

[Jóhann B . Guðmundsson]

On 03/31/2016 02:31 PM, Michal Sekletar wrote:

We don't need to extend the kernel in order to implement this
particular mechanism. After new kernel is installed, you make it
default and mark as "tentative". Then, after first successful boot of
newly added bootloader entry you just remove the flag, because it is
known to work.
I dont see how you plan on implement this if not//with either a 
secondary program loader which stores an redundant environment or an 
kernel support that does the similar/same thing I mean you need to have 
a watchdog support,boot counter  which get's cleared when system decides 
it's up and stable,boot limit which tells it how many times it should 
try with an given entry, an entry which points to which 
kernel/image/snapshot to use right?


I'm pretty sure Kay and Lennart must have thought things through so they 
just dont add just some half ass, none future proof, working solution 
that give administrators and embedded distribution fake notion of 
redundancy or a "fail-safe" when images and or kernel or the OS itself 
get's update/upgraded.


If this cannot or will not be reliably implemented there is no point in 
implementing this in the first place from my pov.


JBG


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

Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

[Jóhann B . Guðmundsson]

On 02/18/2016 11:26 AM, Daniel Mack wrote:

On 02/18/2016 12:19 PM, Jóhann B. Guðmundsson wrote:

>On 02/18/2016 10:22 AM, Daniel Mack wrote:

>>I disagree. All sorts of testing is good for us, and if a PR is breaking
>>downstream Ubuntu, and we recognize that before merging, that's really
>>great.

>
>I'm all for more testing the better but due to downstream fragmentation

Fragmentation? Martin does not apply any patches downstream for his
tests, so I don't see where this fear is coming from?



Irrelevant to Martin.

I meant this as a fragmentation from a broad perspective as in the linux 
ecosystem in whole which in turn reflects itself in upstreams like 
Lennart is about to do in #2621.


If you acknowledge thus start making an exception you must realize you 
effectively start making exceptions for *all* since there is exist no 
singularity in that act.
If the patch in that report gets accepted anyone can submit a patch that 
replaces wheel with another user/group and it would have to be accepted 
since no argument could be made against it, otherwise you would be 
acknowledging that you pick favorites and grant exceptions to only those 
favorites ( in that particular case Debian/Ubuntu would be acknowledge 
as an favorite which puts every other consumer of systemd to 
disadvantage ).


In relevance to this thread by allowing one you are allowing *all* and 
so while Martin and his integration play by the book others might not 
but as you say that can be dealt with if and then when that happens.


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

Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

[Jóhann B . Guðmundsson]

On 02/18/2016 10:43 AM, Martin Pitt wrote:

I'd actually turn it the other way around and claim that if Fedora,
Arch, etc. have downstream tests, then please trigger them too. After
all, failures of them don't block anything (right now, anyway), and
having the extra information in the PRs can only be useful?


Arguably not if upstream test do not detect these things then they 
should be fixed to do so ( which in turn should make all the none 
detected failures be downstream issues )  instead of having every 
downstream consumers if systemd comment on the same issue if fails 
locally with them.


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

Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

[Jóhann B . Guðmundsson]

On 02/18/2016 10:22 AM, Daniel Mack wrote:

I disagree. All sorts of testing is good for us, and if a PR is breaking
downstream Ubuntu, and we recognize that before merging, that's really
great.


I'm all for more testing the better but due to downstream fragmentation 
all these have the same fundamental problem as are with multiple 
downstream issue trackers.


In this case you start slowing down integration if PR start failing in 
one or more downstreams ( Arch,Coreos, Debian,Fedora,Mageia,Ubuntu etc 
and need to start spending time researching if the failure is downstream 
specific and during that time the PR will be in frozen state ) and you 
risk those test system(s) start reporting directly upstream  ( which can 
lead to fun things like this [1]  ) since people will quickly think "I'm 
just going to have all failures and errors reported directly upstream 
instead of having to inspect/deal with downstream myself" and those 
thing start small like with "CI test -- don't merge!"


JBG

1. https://bugzilla.redhat.com/show_bug.cgi?id=1300212
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

[Jóhann B . Guðmundsson]

On 02/18/2016 08:01 AM, Martin Pitt wrote:

So please don't put too much attention to these results yet. I want to
to enable them to see how the testing and communication holds up in
practice, but before this we definitively need to sort out [2] first.


Will failed tests or false positives start auto creating issues on github?

If so is that really the smart thing do to here?

The only test system that should be hooked into upstream should just be 
upstreams own not some downstreams right.


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

Re: [systemd-devel] Moving systemd-bootchart to a standalone repository

[Jóhann B . Guðmundsson]

On 02/17/2016 04:51 PM, Daniel Mack wrote:

Hey,

[I've put all people in Cc who have had more than one commit related to
systemd-bootchart in the past]

As part of our spring cleaning, we've been thinking about giving
systemd-bootchart a new home, in a new repository of its own. I've been
working on this and put the result here:


What's the reason for splitting it out into it's own repository as 
what's the criteria you used to determine that which may or may not be 
applicable to other bits of systemd?+


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

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Jóhann B . Guðmundsson]

On 02/11/2016 05:47 PM, Lennart Poettering wrote:

On Thu, 11.02.16 17:32, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:


I just tagged the v229 release of systemd. Enjoy!

CHANGES WITH 229:

 * The coredump collection logic has been reworked: when a coredump is
   collected it is now written to disk, compressed and processed
   (including stacktrace extraction) from a new instantiated service
   systemd-coredump@.service.

Is it enough to disable this type service unit to completely disable
coredump or will users have to for example set Storage=none in coredump.conf
and or other tweaks and if so which ones?

Try the man page systemd-coredump(8), first paragraph.


I do believe that's not enough to completely disable this and confusing 
at best I mean is the man page refering to 
/usr/lib/sysctl.d/50-coredump.conf
or /etc/systemd/coredump.conf which is what the administrator would 
associate this with since you know he was reading that particular man page.


There is a quite the difference of doing "ln -s /dev/null 
/etc/sysctl.d/50-coredump.conf && sysctl -p or 
/lib/systemd/systemd-sysctl" if systemd does not pick up the sysctl changes
vs administrators creating a symlink to /etc/systemd/coredump.conf 
disable this and run systemctl daemon-reload while the former is 
probably what's being refereed to.


And based on how that got implemented I have to ask cant this be disable 
completely as a switch in /etc/systemd/coredump.conf without having to 
have administrators jump through hoops, create symlinks and what not?





 * A new service setting RuntimeMaxSec= has been added that may be used
   to specify a maximum runtime for a service. If the timeout is hit, 
the
   service is terminated and put into a failure state.

This does not sound right, why put it into failure state if I as an admin
specifically told the the service it could run for maximum X time and then
it should stop? ( after that time period the type unit should be stopped
cleanly basically systemctl stop foo.service and the state be exactly the
same as it yields right ? )

I think yours appears to be a different usecase than what
RUntimeMaxSec= currently covers.


What's the usecase you had in mind and why leave it in failed state?

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

Re: [systemd-devel] [RFC] the chopping block

[Jóhann B . Guðmundsson]

On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

>2) compat support for libsystemd-login.so and friends (these were
>merged into a single libsystemd.so a long time ago). We are still
>building compat libraries to ease the transition, but that was a
>long time ago, hence I'd really love to see this go. Any distro
>still using this?

Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.



The upstream bug is few months short of it's 2 year anniversary and this 
move will just get the samba developers to apply the patch in that 
upstream report and close that bug.


Andrew is there any reason the patch in that upstream report has not 
been applied and samba moved to use libsystemd.so?


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

Re: [systemd-devel] [RFC] the chopping block

[Jóhann B . Guðmundsson]

On 02/11/2016 09:44 PM, Andrew Bartlett wrote:

On Thu, 2016-02-11 at 20:04 +, Jóhann B. Guðmundsson wrote:

On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

2) compat support for libsystemd-login.so and friends (these
were
merged into a single libsystemd.so a long time ago). We are
still
building compat libraries to ease the transition, but that
was a
long time ago, hence I'd really love to see this go. Any
distro
still using this?

Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers
installed.


The upstream bug is few months short of it's 2 year anniversary and
this
move will just get the samba developers to apply the patch in that
upstream report and close that bug.

Andrew is there any reason the patch in that upstream report has not
been applied and samba moved to use libsystemd.so?

There isn't a patch for upstream master and the 4.1 patch doesn't
apply.

(I realise it may be trivial to fix it, but we need it tested against
old and new systemd installs etc, so if I can get such a patch it will
be much easier)

Sorry,


There was someone ( Armin ) on this thread that responded this had 
already been applied upstream since last summer which inconsistent with 
the current status of the bug in your tracker and your response and I 
think it's safe to assume you know better anyway you are aware of what's 
about to take place and need to adjust accordingly as do rest of 
downstreams that still might be using/relying on this although ( thus 
far ) samba seems to be the only affected by this change.


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

Re: [systemd-devel] [RFC] the chopping block

[Jóhann B . Guðmundsson]

On 02/11/2016 08:41 PM, Armin K. wrote:

On 11.02.2016 21:04, Jóhann B. Guðmundsson wrote:


On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

2) compat support for libsystemd-login.so and friends (these were
merged into a single libsystemd.so a long time ago). We are still
building compat libraries to ease the transition, but that was a
long time ago, hence I'd really love to see this go. Any distro
still using this?

Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.


The upstream bug is few months short of it's 2 year anniversary and this move 
will just get the samba developers to apply the patch in that upstream report 
and close that bug.

Andrew is there any reason the patch in that upstream report has not been 
applied and samba moved to use libsystemd.so?

It has been applied at least since the last summer.


If that's the case the samba community does not close open bugs as 
fixed, what a waste of time that must be for everybody anyway then the 
only concern ( thus far ) has already been fixed upstream.


JBG

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

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Jóhann B . Guðmundsson]

On 02/11/2016 04:50 PM, Lennart Poettering wrote:

Heya!

I just tagged the v229 release of systemd. Enjoy!

CHANGES WITH 229:

 * The coredump collection logic has been reworked: when a coredump is
   collected it is now written to disk, compressed and processed
   (including stacktrace extraction) from a new instantiated service
   systemd-coredump@.service.


Is it enough to disable this type service unit to completely disable 
coredump or will users have to for example set Storage=none in 
coredump.conf and or other tweaks and if so which ones?





 * A new service setting RuntimeMaxSec= has been added that may be used
   to specify a maximum runtime for a service. If the timeout is hit, 
the
   service is terminated and put into a failure state.


This does not sound right, why put it into failure state if I as an 
admin specifically told the the service it could run for maximum X time 
and then it should stop? ( after that time period the type unit should 
be stopped cleanly basically systemctl stop foo.service and the state be 
exactly the same as it yields right ? )


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

Re: [systemd-devel] known but not-listed units

[Jóhann B . Guðmundsson]

On 01/14/2016 03:01 PM, Lennart Poettering wrote:

We currently do not show runtime generated unit files among the output
of "systemctl list-unit-files", but it would probably make sense


Aren't these files auto generated on each bootup/reload/restart thus 
exposing them is likely to cause confusion for administrators
( they start fiddling with the autogenerated units as opposed to what 
they are autogenerated from and wonder why those changes get lost ) 
hence it would be better continuing not exposing them right?


At least I would think generators would need to add to their generated 
files "# DO NOT EDIT THIS FILE" in addition to "# Automatically 
generated by $generator" to be clear on this.


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

Re: [systemd-devel] CODENAME field in /etc/os-release

[Jóhann B . Guðmundsson]

Use the existing fields as in

NAME=
VERSION=
ID=
VERSION_ID=
PRETTY_NAME=
VARIANT=
VARIANT_ID=

Adding additional codename field serves no purpose or value which the 
previous fields do not already cover.

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

Re: [systemd-devel] Do we need /dev/core?

[Jóhann B . Guðmundsson]

On 12/30/2015 11:24 AM, Marco d'Itri wrote:

Does anybody know about something actually using /dev/core or is it yet
another instance of cargo cult sysadmining?

A Debian code search shows only two packages using it. In tests.
Wrongly.
https://codesearch.debian.net/results/%22%2Fdev%2Fcore%22/page_0

Can we officially deprecate it and then remove the link?


You should ask that question on the kernel mailinglist and or on the 
Debian devel list if they want to remove that symbolic link to /proc/kcore


I suspect on both those list the response will be the same NO we wont do 
that but that's for them to decide ;)


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

Re: [systemd-devel] Do we need /dev/core?

[Jóhann B . Guðmundsson]

On 12/30/2015 11:44 AM, Marco d'Itri wrote:

On Dec 30, "Jóhann B. Guðmundsson" <johan...@gmail.com> wrote:


You should ask that question on the kernel mailinglist and or on the Debian
devel list if they want to remove that symbolic link to /proc/kcore

I am already dealing with the Debian side (and there is no point in
removing the link if the other distributions will not follow), but I am
not sure why LKML should dictate the policy here.


Because /dev and /proc is their territory and if /dev/core should be 
removed from standard symlinks creation in udev that's probably for them 
to decide.


Why do you want to remove it, what harm does that symlink do?
___
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 07:48 PM, Lennart Poettering wrote:

I see no reason why systemd should be involved with this. Just make
etcd a proper daemon, and read its config data directly, rather then
serializing it into the command line.


In sys v initscript it started out as variable options, placed on top 
for administrator ease of changeability then due the share size and 
complexity of the sys v initscript it evolved it into environment files 
which led to file location based fragmentation between distribution ( 
and is now hindering share-ability of type unit files between 
distributions ) but never through all those decades did someone go and 
fix the underlying problem which is as you point out lack of daemon 
reading configuration file.


The same pattern has started to re-emerge in a form of an workaround in 
systemd by using drop-ins containing [Service] Environment= or 
EnviromentFile=, which I suspect they are doing based on his description 
either themselves or they have administrators do that to overwrite those 
entry's since they generate that metadata file ( which is more likely )


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/21/2015 04:36 PM, Michael Biebl wrote:

2015-12-21 17:30 GMT+01:00 Jóhann B. Guðmundsson <johan...@gmail.com>:

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

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

[Jóhann B . Guðmundsson]

On 12/21/2015 01:30 PM, Reindl Harald wrote:
ExecStart=/path/to/daemon FOO would cut you from distro-changes in 
other params and explained abvoe sooner or later lead in failing and 
could even be security relevant depending on new options or removed 
options in the distro-unit 


You do realize you have the exact same chances with an environment entry 
line do you not?


The options being used there could be deprecated in the daemon startup 
and for those daemon/services that are capable of reading their own 
configuration files  ( and thus those environment lines are not 
applicable to )  are never changed on updates..


When an administrators makes a change to an configuration ( or in this 
case type unit ) he is stating that he's deviating from the 
distributions shipped defaults for that components and since there is no 
reliable way for a system to detect and determine manual changes in 
configuration, there is always the risk that an update will break 
running system ( the administrators made changes ) which is why the 
configuration files for a running daemon/service are saved as copy's and 
the administrator who has made the deviation is expected to review and 
apply those changes himself.


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/18/2015 04:00 PM, Michael Biebl wrote:

2015-12-09 20:46 GMT+01:00 Lennart Poettering :

On Wed, 09.12.15 18:27, Soumya Koduri (skod...@redhat.com) wrote:


Hi,

I have created a systemd.unit(nfs-ganesha.service) file as below :

[Unit]

After=nfs-ganesha-config.service
Requires=nfs-ganesha-config.service


[Service]
EnvironmentFile=-/run/sysconfig/ganesha
ExecStart=/usr/bin/ganesha.nfsd $OPTIONS ${EPOCH}

(But honestly, there's really no point in trying to dynamically
convert stuff into a file that is suitable for EnvironmentFile=. I
mean, if you want a shell script, then use a shell script, and invoke
that from the main daemon's ExecStart= line, and make it exec the real
daemon as last step. There's really no point in playing these
multi-service conversion games. Also /etc/sysconfig is a Redhatism
that should really go away, the whole concept is flawed. Adding a new
/run/sysconfig/ certainly makes that even worse.)

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 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.

Then distros like Fedora could do a one-time migration of their
settings in /etc/sysconfig/foobar and drop the file after the upgrade.


This makes no sense.

Here you are just adding an extra line with no value on top of requiring 
some form of standardize the $OPTS var name across daemons ( as opposed 
to administrators simply change the value of the line directly ).


Best practice and the least amount of work for administrator ( both in 
editing and for other administrators to keep taps on changes made by 
others ) is to copy/edit the entire unit.


Lennart can better explain what value he saw in introducing those 
snippets compared to that since he introduced them in the first place.


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/21/2015 01:00 PM, Reindl Harald wrote:



Am 21.12.2015 um 12:40 schrieb Jóhann B. Guðmundsson:

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.

Then distros like Fedora could do a one-time migration of their
settings in /etc/sysconfig/foobar and drop the file after the upgrade.


This makes no sense.


for you!


What he proposed is redundant and adds an extra line to the unit file 
and in addition requires some distro's acceptance that upstream needs to 
be aware of when it creates the unit for it's daemon/service.


His proposal

[Unit]
Description=Sample unit
# Unesseray line added
Environment=OPTS=FOO

[Service]
ExecStart=/path/to/daemon $OPTS

[Install]
WantedBy=multi-user.target

VS standard without any environment entry and does not require upstream 
being aware of any standardization or lack there of in downstream 
distributions.


[Unit]
Description=Sample unit

[Service]
ExecStart=/path/to/daemon FOO

[Install]
WantedBy=multi-user.target

By all means enlighten me the benefits of his proposal which makes sense 
and does not add unnecessary line to the type unit file along with the 
complexity it might bring ( think larger type units ).


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/21/2015 04:02 PM, Michael Biebl wrote:

2015-12-21 17:00 GMT+01:00 Jóhann B. Guðmundsson <johan...@gmail.com>:

No what's obvious is it does not add any value not et all

Well, I can reiterate the points, but I suggest you just read this thread again.

and not all

daemons and service support additional environmental options added to them
et all so adding an empty environmental line just for the sake of adding it
makes even less sense,

Obviously, if a daemon doesn't support command line (or env) args, you
would not add a $OPTS.





It's an added work to add the environmental line to begin with and it's 
an equal amount of work for administrators to change the environmental 
line or the Exec= line(s) so the benefit is none

( note that I'm referring to systemd being the only initsystem ).

With environmental files administrators will have to keep tabs on two 
files ( the unit file along with the associated environmental file ) as 
well as their location ( due to distributions locating those files on 
different places ) and upstream would have to support multiple 
distribution specific unit as a results of that or downstream packagers 
carry an additional patch which adds their distribution location to the 
upstream unit file.


In a distribution that does or has to support multiple init systems 
things look quite differently because there the component has to be 
cross compatible with all the shipped/supported init system so you have 
basically no other option but to include an environmental file reference 
in the unit as well as specifying it in any other init system startup 
script and have administrators make their changes there so those changes 
can be retained ( on updates/upgrades ) regardless of which init system 
is or was in use.


In Fedora the plan was to obsolete them altogether since those lines and 
files did not add any benefits since systemd got introduced and 
implemented as the only init system ( this became very clear in in F15 ) .


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/21/2015 02:15 PM, Reindl Harald wrote:


and since you say this what is your business for taking 
"EnvironmentFile" away from administrators area - my config, take your 
hands from it instead propose to break it - nobody cares if you would 
something do in a different way as long you are not trying to force 
others change their setups for no good reason


Because environmental lines or files that are spesific to daemon startup 
( not it's environment ) have no value being there in the first place 
none what so ever and I'm saying this after going through and migrate 
around 400 legacy sysv initscripts and inspecting about 200 more.


They might have served some value in the legacy sysv initscripts since 
those where in the lines of hundreds ( the largest I migrated was about 
800 - 900 lines long ) but for some reason distribution decided to move 
the OPT= or OPTIONS= from the sysv scripts and into their own specific 
environmental file instead ( you used to configure it directly in the 
initscript itself and upstream could just ship it like that regardless 
of the distribution most likely distribution did so due to the share 
size of those legacy sysv initscripts ).


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/21/2015 03:17 PM, Michael Biebl wrote:

The benefit of that instead of having to override the complete
ExecStart line should be obvious and has already be mentioned in this
very thread.


No what's obvious is it does not add any value not et all and not all 
daemons and service support additional environmental options added to 
them et all so adding an empty environmental line just for the sake of 
adding it makes even less sense,

___
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/11/2015 03:56 AM, Andrei Borzenkov wrote:

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:

Care to show example how it should be done from your point of view? 
So that they can actully be compared?


You just create an configuration snipped that replaces the ExecStart 
line for the daemon in the unit file with startup options for the daemon 
which contains the options you want to change or copy/edit the full unit 
and replace it.


In his sample case above where he's using ExecStart=/usr/sbin/httpd 
$OPTIONS -D FOREGROUND and the environment file /etc/sysconfig/httpd
you would create an configuration snippet which contains 
"ExecStart=/usr/sbin/httpd -D testserver -D FOREGROUND" instead .


The only reason I can think of why distributions decided to split 
configuration out of the legacy sys v initscripts to begin ( you used to 
just tweak it there ) is because the legacy sysv initscript had become 
such a mess that administrator ended up breaking them when they did but 
perhaps someone else posses the historic knowledge why distributions 
started doing that.


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/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"

[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

Re: [systemd-devel] RFC: Setting TasksMax= by default

[Jóhann B . Guðmundsson]

On 11/13/2015 01:49 PM, Lennart Poettering wrote:

Heya!

So, I am tempted to make the following changes to systemd, and was
wondering about opinions about it:

a) The first change is rather uncontroversial I presume: I'd like to
set DefaultTasksAccounting=yes in system.conf by default. This
means we get accounting of the number of tasks per unit enabled by
default. Effectively this turns on the "pids" cgroup controller for
all units. According to the cgroups folks this is OK as this
specific controller is not particularly costly. This means that by
default "systemctl status" will show a "Tasks: " line then, showing
the number of tasks in the service. cgtop will be more efficient,
too, then.


Arguably this should be called system instead of default for system wide 
settings where applicable ( you need to keep a clear distinction which 
option belongs where and what it affects )


Will people be able to disable this per type unit (  set 
"UnitTasksAccounting=yes/no" )


Users sets SystemTasksAccounting=yes in system.conf but turns off task 
accounting for b.service while while keeping it for every other type unit ?


Or

Users sets SystemTasksAccounting=no in system.conf but enables task 
accounting for a.service while while keeping it disabled for every other 
type unit ?




b) I'd like to introduce DefaultTasksMax= that controls the default
value of the per-unit TasksMax= by default, and would like it to
set to some value such 1024 out-of-the-box. This will mean that any
service or scope created will by default be limited to 1024
tasks. This of course is a change from before that has the
potential to break some daemons that maintain an excessive number
of processes or threads. However, I think it's a much better choice
to raise the limit for them, rather than stay unlimited for all
services by default. I think 1024 is not particularly low, but also
not particularly high. Note that the kernel by default limits the
number of processes to 32K in total anyway.


Should there not be two options "SystemTasksMax" which alters the kernel 
default limits and UnitTaskMax  which controls the default value of 
per-unit ?




c) In logind.conf I intend to add a TasksMax= setting that sets the
number of tasks for user sessions, and overrides the systemd-wide
setting for user scopes. It would also be set out-of-the-box, and
default to something like 8K or so. (Note that this is very similar
to setting RLIMIT_NPROC via /etc/security/limits.conf, but has the
benefit of covering also suid binaries, being nicely queriable
via systemctl status and controllable during runtime via "systemctl
set-property" and so on)


Should not this be SessionTasksMax= setting? to clearly disquince this 
from other task mask settings ( accommodated by SessionTasksAccounting= )


d) in systemd's own unit files we'll configure much lower settings by
default, since we know how many tasks they require.





Putting this altogether you have in systemd.conf something along the 
lines of


# Enable/disable system wide task accounting
SystemTasksAccounting=yes/no


# Set system wide task limit
SystemTasksMax=32768

# Enables/disable task accounting for type units
UnitTasksAccounting=yes/no

# Set type unit wide task limit
UnitTaskMax=1024

# Enable/disable session task accounting
SessionTasksAccounting=yes/no

# Set session task limit
SessionTasksMax=8000

For type units people could overwrite system wide defaults via

[Unit]
UnitTasksAccounting=yes/no
UnitTaskMax=64

For sessions people could overwrite system wide defaults ( logind.conf ) via
SessionTasksAccounting=yes/no
SessionTasksMax=12000

Status needs to show the current usage and max available and daemon 
reload should issue a warning on or fail if the max value for type units 
and sessions is set higher than the value of system tasks Max


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

Re: [systemd-devel] [packaging] split of systemd package

[Jóhann B . Guðmundsson]

On 11/11/2015 10:47 AM, Lukáš Nykrýn wrote:

Hi,

During systemd.conf we have discussed some recommendation for
downstreams, how they could split systemd to subpackages, so lets
continue that discussion here.


I thought the conscious was not recommending downstream to split systemd 
into subpackages?


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

Re: [systemd-devel] [packaging] split of systemd package

[Jóhann B . Guðmundsson]

On 11/11/2015 10:57 AM, Michal Sekletar wrote:

On Wed, Nov 11, 2015 at 11:52 AM, Jóhann B. Guðmundsson
<johan...@gmail.com> wrote:

I thought the conscious was not recommending downstream to split systemd
into subpackages?


This decision was recently (at systemd.conf) reevaluated :)



Not everybody can attend conference due to wide variety of reasons so 
making decisions there without the input of those in the community that 
could not attend is disrespectful.


Anyway what was the cause for the reevaluation in other words why did 
people change their mind in this regard?


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

Re: [systemd-devel] [packaging] split of systemd package

[Jóhann B . Guðmundsson]

On 11/11/2015 01:12 PM, Michael Biebl wrote:

2015-11-11 12:58 GMT+01:00 Martin Pitt :

Hello all,

in case it's useful, this is how we split them in Debian.

However, is this even a topic for upstream, apart from giving
recommendations? I. e. do you actually consider putting this kind of
split into the upstream build system à la "make install-"?

I brought this issue up during my talk and recommended that we
(downstream distros) might collaborate on this so where possible we
have more consistency across distros.

Since systemd-devel is rather low-volume these days it seemed ok to
have these discussions here.
If Lennart would like to see it elsewhere, that's fine of course. But
I actually value his feedback on this matter.




Arguable there should be a neutral ground somewhere ( 
systemd-cross-distro list of some sort ) where distribution can 
collaborate on matters like this since there are other things that need 
to be discussed and need to be sorted out other than just splitting 
systemd into separated components.


Unit files for various daemon and services, naming of component which 
can directly affect names of type units themselves, deprecation of 
environmental files in units ( not sure how or if they are used in 
Debian but in Fedora there exist /etc/sysconfig/foo files which have 
become obsoleted for daemon and service with the introduction of systemd 
) cross distro collaboration of integration of wide variety of systemd 
components ( timer units, networkd etc ) so fourth and so on.


Hopefully the outcome of broader discussion like that would result in 
mutual proposal where each participant distribution could present to 
their distribution for distro wide acceptance and integration.


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

Re: [systemd-devel] [packaging] split of systemd package

[Jóhann B . Guðmundsson]

On 11/11/2015 03:51 PM, Zbigniew Jędrzejewski-Szmek wrote:

Why not systemd-devel?


Because these aren't development related discussion and there is a need 
for separated collaborated git repository to prevent duplication of 
downstream work etc.


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

Re: [systemd-devel] Detect if a script runs during bootup

[Jóhann B . Guðmundsson]

On 11/11/2015 03:39 PM, Frank Steiner wrote:

If I was able to work with systemd unit files, I could perfectly
do what I want, but I'm stuck with this LSB file.

Why are you stuck with that lsb file and what exactly does it do?
( Paste the content of it )

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

Re: [systemd-devel] [packaging] split of systemd package

[Jóhann B . Guðmundsson]

On 11/11/2015 11:58 AM, Martin Pitt wrote:

However, is this even a topic for upstream,


I would argue not.

I would argue that this is a downstream collaboration matter in which a) 
the split should be the same regardless of distribution and the sub 
components should be split in same manner across all distribution so it 
does not matter if you are running Arch/Debian/Ubuntu/Fedora etc. the 
documentation and required actions are the same for the consumer.


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

Re: [systemd-devel] [packaging] split of systemd package

[Jóhann B . Guðmundsson]

On 11/11/2015 04:04 PM, Reindl Harald wrote:



Am 11.11.2015 um 17:03 schrieb Jóhann B. Guðmundsson:

On 11/11/2015 03:51 PM, Zbigniew Jędrzejewski-Szmek wrote:

Why not systemd-devel?


Because these aren't development related discussion


this list was multiple times statet also as users-list by Lennart 
himself, just use Google to find that statement in the archive


I dont see to what relevance this being user list or development list is 
here.


These are discussion about integration of the building block of the OS 
in downstream distribution which upstream should only be involved with 
for guidance.
( upstream should never be maintaining their own component in downstream 
distribution for obvious reasons ).



and there is a need for separated collaborated git
repository to prevent duplication of downstream work etc.


why?


To coordinate and oversee and collectively share work done between 
distribution integrating the relevant components in their distribution.


Basically the same thing we ( we as in major distribution + few I 
personally never heard of ) did in 2011 with the exception that now 
Debian and Ubuntu have joined the party and we would have a shared git 
repository to use instead of everyone having one either on an individual 
level or distribution level.


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

Re: [systemd-devel] [packaging] split of systemd package

[Jóhann B . Guðmundsson]

On 11/11/2015 08:28 PM, Michael Biebl wrote:

2015-11-11 21:21 GMT+01:00 Jóhann B. Guðmundsson <johan...@gmail.com>:
[snip]

To coordinate and oversee and collectively share work done between
distribution integrating the relevant components in their distribution.

And now you started an unrelated meta-discussion. Please do that in a
separate thread and don't hijack this one.


Please discuss this downstream since downstream packaging is an 
downstream matter.


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

Re: [systemd-devel] [packaging] split of systemd package

[Jóhann B . Guðmundsson]

On 11/11/2015 08:38 PM, Reindl Harald wrote:



Am 11.11.2015 um 21:21 schrieb Jóhann B. Guðmundsson:

On 11/11/2015 04:04 PM, Reindl Harald wrote:



Am 11.11.2015 um 17:03 schrieb Jóhann B. Guðmundsson:

On 11/11/2015 03:51 PM, Zbigniew Jędrzejewski-Szmek wrote:

Why not systemd-devel?


Because these aren't development related discussion


this list was multiple times statet also as users-list by Lennart
himself, just use Google to find that statement in the archive


I dont see to what relevance this being user list or development list is
here


interesting - so what did you try to tell the world with "because 
these aren't development related discussion"?


Last time I checked downstream distributions packaging problems is not 
upstream development discussions.




you are just pissed off because you where not present at the 
conference and nobody asked you before talk aboput something - that's 
it - period


I have you know I chose rather to pay for a ticket to be shared with 
individuals that could not afford it rather then participate in a 
conference where the community was being charge for reflecting on itself.


It's an ethical thing feel free to contact Nils if you need confirmation 
of that.


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

Re: [systemd-devel] A few GitHub team changes

[Jóhann B . Guðmundsson]

On 10/13/2015 07:07 PM, David Timothy Strauss wrote:

entire members


What makes up that members list [1] in the first place?

https://github.com/orgs/systemd/people
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] amavis

[Jóhann B . Guðmundsson]

On 07/02/2015 02:04 PM, François Vocel wrote:

Hello,

I installed Kolab on CentOS 7.
The amavis service will not start.


There already is a bug report about this [1] but most common cause for 
amavisd not starting is the configuration files is misconfigured


https://bugzilla.redhat.com/show_bug.cgi?id=1177819
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stricter handling of failing mounts during boot under systemd - crap idea !

[Jóhann B . Guðmundsson]

On 06/29/2015 02:08 PM, jon wrote:

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system

I just installed debian 8.1, on the whole my reaction is mixed, one
thing however really pisses me off more than any other

5.6.1. Stricter handling of failing mounts during boot under systemd

This is not Stricter it is a change in default behaviour.

This change is a shit idea, who do I shout at to get the behaviour
modified to back to sensible ?



The systemd community only recommends what downstream consumers of it 
should do but does not dictate or othewise decided anything how those 
consumers eventually decide to implement systemd so if you dont like how 
systemd is implemented in Debian you should voice your concerns with the 
Debian community.


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

Re: [systemd-devel] Stricter handling of failing mounts during boot under systemd - crap idea !

[Jóhann B . Guðmundsson]

On 06/29/2015 04:17 PM, Andrei Borzenkov wrote:

No. systemd changed interpretation of well established configurations
in incompatible way. There is no way to retain existing behavior. It is
far from recommends - it is my way or highway.


Not following which changed interpretation of well established 
configurations systemd has changed here.


Do you have any reliable way to determine which file systems are 
important and which ones can be skipped at bootup?


What do you propose systemd should do if a device listed in fstab is not 
available at bootup and that device has not been flagged that it could 
be skipped?


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

Re: [systemd-devel] Stricter handling of failing mounts during boot under systemd - crap idea !

[Jóhann B . Guðmundsson]

On 06/29/2015 03:01 PM, jon wrote:

On Mon, 2015-06-29 at 14:21 +, Jóhann B. Guðmundsson wrote:

On 06/29/2015 02:08 PM, jon wrote:

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system

I just installed debian 8.1, on the whole my reaction is mixed, one
thing however really pisses me off more than any other

5.6.1. Stricter handling of failing mounts during boot under systemd

This is not Stricter it is a change in default behaviour.

This change is a shit idea, who do I shout at to get the behaviour
modified to back to sensible ?


The systemd community only recommends what downstream consumers of it
should do but does not dictate or othewise decided anything how those
consumers eventually decide to implement systemd so if you dont like how
systemd is implemented in Debian you should voice your concerns with the
Debian community.

Ok

Who writes/maintains the code that parses nofail in /etc/fstab ?
Who writes/maintains the typical system boot code (whatever has replaced
rc.sysinit) ?

I suspect the answer to both is the systemd maintainers, in which case
is this not the correct place to bitch about it ?


util-linux ( see man mount ) is what provides the nofail option and I 
dont follow what you mean by getting the behaviour to modify it back to 
sensible since systemd does already do what is sensible to do and always 
has.


The fact is systemd has no means in figuring out which file systems are 
crucial and which ones are not hence it has always done the safe thing 
and dropped users to the emergency target if device listed in fstab has 
not appeared after a period of time so administrators have had to tell 
systemd which ones they consider to be none crucial to the bootup 
process by adding nofail mount option to the relevant device entry in 
fstab so I'm not sure what the Debian community considers as  stricter 
handling of failing mounts during boot under systemd since this has 
always been the case with systemd.


Perhaps systemd's behaviour is different from one ( or all ) of the 
other initsystem(s) that exist in Debian and that's what this 
documentation entry is about but not about any changes to systemd itself.


My advice to you is simply to add the nofail mount options to the device 
entries in fstab for devices you consider not being crucial to the 
bootup process and systemd will happily carry on your boot process 
without dropping you to the emergency target if that device is not 
available.


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

Re: [systemd-devel] Creating units using D-Bus

[Jóhann B. Guðmundsson]

On 06/09/2015 10:21 PM, Lennart Poettering wrote:

On Tue, 09.06.15 19:33, Jakub Skořepa (ja...@skorepa.info) wrote:


Hello,
My name is Jakub Skořepa and I'm working on Cockpit UI for Systemd
Timers.

For that I need to create and modify systemd unit files. Cockpit uses D
-Bus for everything so I need D-Bus API for that. I think that it would
be beneficial if systemd was able to create unit files on-the-fly using
through D-Bus method call.

You can do that already, in the concept of transient units. However,
these units are not persistent, they are stored in /run and go away on
reboots. Google for the StartTransientUnit() bus call for details.

I think it would be a good idea to also allow to create persisent
units in a similar way eventually. However, that's not as obvious and
easy as it sounds, it starts from the question where to store those
units. Cron-like semantics would suggest somewhere below /var, but
that means they aren't available at early boot, and we'd have to
reload the configuration and requeue all jobs when /var appears. Which
means we'd have to put them in /etc instead, which however is
suboptimal for many usecases

I think I'd be willing to merge a patch that adds adds a new bus call
CreatePersistentUnit() that works like StartTransientUnit() except
that it only creates but not starts a unit, and that it stores the
unit in /etc. (Note: the only reason StartTransientUnit() not only
creates but also starts a unit is because the unit would otherwise be
GC'ed away immediately and not be reconstructable after that...)




I hate to say this since I'm against litter unit files across the entire 
filesystem like infective disease and administrator then have to run 
around trying to chase them down but is it not better to store this 
under /srv somewhere [1], not etc, so it wont conflicts with Stateless 
Systems, Factory Reset, Golden Master Systems?


On top of that if this gets created under /etc it's a free for all for 
administers to tinker with.


Arguably supporting this et all or supporting this without forcefully 
having to bind those timer units with an existing type service unit is a 
mistake so it might just be better to direct them to install and use 
cron instead and have cockpit drop a snippet into /etc/cron.d and the 
likes instead


Jakub,Stephen what's the end game with this as in what kind of timer 
definitions do you expect administrator be doing and support from the 
cockpit UI?


1. http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Creating units using D-Bus

[Jóhann B. Guðmundsson]

On 06/10/2015 12:30 PM, Stephen Gallagher wrote:


A good overview of what we're aiming to accomplish can be found here: h
ttps://github.com/cockpit-project/cockpit/wiki/Feature:-Systemd
-timers#stories

Though at the end of the day, it might be fair to say that systemd
timers are cool and very capable and we really just want to have a
decent UI for people to manipulate them. Cockpit seems like a good
place since it already does management of a lot of other systemd
functionality for Fedora Server.

If you have specific questions or concerns with that design, we'd love
to hear them.


Timers are not suited to all administrated tasks ( only the ones that 
relate to bootup,hardware and daemons ) and you seem to have fallen into 
the trap of taking the cron concept and start applying it to timers ( as 
opposed to simply continue to use cron )  when it's not the same thing, 
( to me it is the same as you take the run level concept and apply it to 
systemd boot targets and think that it's the same thing) and what's 
describe there on that story page is something that cron is better 
suited to handle ( and probably much easier to implement as well ).


Now as I mentioned before you need to bind every timer unit that get's 
created with the relevant service running on the host. so when a daemon 
is started or stopped or even uninstalled ( think for example postgresql 
+ postgresql backup timer service ) , or device appears then disappears 
the relevant timer unit is stopped in the process however timer units 
are not suitable for end user tasks ( which are the only thing that is 
listed there on that story page ).


As I mentioned on numerous occasion when I was driving the cron to timer 
migration effort in Fedora that timers and cron are solution that 
complement each other not replace each other, which why the cron jobs to 
be migrated to native times units was limited to roughly half of the 
total of shipped cron jobs in the distribution.


I guess the best way for you to realize this is to set up a batch server 
with 20, 50 or hundreds of timer units and maintain it and you will 
quickly understand timers shortcomings and why they should not be used 
for end users usecase like the ones on that story page.


You most certainly can make administrators life more hell by using 
timers for all usecases, just like you can drive on the wrong side of 
the road but you shouldn't.


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

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[Jóhann B. Guðmundsson]

On 06/10/2015 03:09 PM, Lennart Poettering wrote:

On Wed, 10.06.15 14:53, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:


WHat really surprises me about the whole discussion is that we cannot
be the first ones running into this. Given the success of github this
must be a common issue. And if it is, then either github is actually
prety bad, or I am too stuck in my bugzilla mindset and haven't really
grokked the github way of doing things yet.

If you want good review tool, why not use gerrit?

We do not have the resources to maintain our own infrastructure.

In term of manpower we have 452 code contributors and 1170 members
subscribed to this list.

Then there are several means to fund that infrastructure so could you please
clarify how you come to this conclusion that we are short on resources?

lurkers and admins who are committed to continously run services
for us for free over years are quite different things.

Also, systemd is not an organization, we are just some losely
affiliated hackers. We have no budget, we have no money, we cannot
employ anyone, and we have zero intention to change that and acquire
budget/money/administration.


o_O

Without proper infrastructure ( or at least the wills to acquire such )  
how can you ( or any of us for that matter ) with a straight face 
advocate for consolidation and call systemd the modern building block of 
an OS ( which arguably means this is second component to the Linux 
kernel ) and sell distribution and companies that it should be what they 
rely on?


All these years we have work hard on all distribution and embedded 
switch to us, rely on us and when push comes to shove we go meh we 
have no intention to go to the next level to properly support you?


Am I the only one here that feels any obligation and responsibility to 
our downstream consumers?


I need a drink...

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

Re: [systemd-devel] Creating units using D-Bus

[Jóhann B. Guðmundsson]

On 06/10/2015 03:02 PM, Stephen Gallagher wrote:

You make some good points Jóhann. It probably does make sense to focus
(at least at first) on managing timer units shipped alongside services
as opposed to trying to develop a UI for managing arbitrary timer
units. I'll discuss this with some of my colleagues.

That said, there still may be some value in enabling the creation of
new timer units for these purposes. (For example, there may be timers
that are only useful if two normally-unrelated services are installed,
so neither one would be likely to ship such a timer in their package,
even disabled). But it's hard to say whether that's worth designing for
or solving by shipping additional packages with helper units.


Now that I see that you have started to understand what I tried to 
convey when running that cron to timer migration but failed miserably in 
doings so, going to say that value is an illusion Ithrow in another ( 
real life ) example to complex matters further.


Let's use this drupal related cron job as an example |0 * * * * wget -O 
- -q -t 1 http://www.example.com/cron.php;| that many will be familiar 
with which you would migrate to native systemd timers.


Shipping this with drupal cannot be done since you cannot bind that to a 
specific web server ( the installed server might be apache, might be 
lighthttp or might be nginx etc ) not binding it to the web server will 
keep this timer unit running with all it downside once the administrator 
shuts down the webserver ( as happens currently with cron ).


What I'm trying to emphasize here there exist only one to one mapping 
with each service ( or target )  and timer unit and those two things 
need to be bound together.


With my former cron to timer feature and serverWG hat on, what I would 
propose and do which is quite the opposite from what you propose here  
is have all components ship their cron job in a separated sub-package ( 
those are mostly crap anyway ) then design the cockpit UI in such manner 
that dissociates cron job and uses generic term like for example 
scheduled task which covers both solution and whatever the future 
might bring and offers the user to create an arbitrary task ( which 
would use cron and have screen(s) tailored to that and create and 
associate task to an service ( with screen(s) tailored to that which 
would use timers )


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

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[Jóhann B. Guðmundsson]

On 06/10/2015 05:46 PM, Greg KH wrote:

There's also no real need for it, I don't understand why you keep
insisting there is given how well things have been working so far.


I do understand and am aware of the complication ( legal and otherwise 
social aspect of it etc ) involved with bringing funds to the project.


Thou you might feel things have been working so far I do not.

Has it worked? yes barely, Could we do better? very much so.

I feel that the community has been showing growth pain for quite 
sometime. patches sent to the mailinglist have gone unnoticed, 
unreviewed. bugs filed in bz.fd.o being poorly handled etc.


That is why I started working ( a while back ) on finding suitable bug 
tracker, buying the systemd.community domain etc. with sole intent to 
offload work of developers ( and show up with proof of concept on one 
the hackfest to start this discussion for real )


The reason I'm being so persistent is because I believe this is the 
right course forward at this point in time to offload work from 
developers and for the growth and improvement of the project hence I 
should give it my best to try to see that through.


Also I'm afraid that the move to github will not yield the result that 
is being sought and arguably is necessary ( most certainly not alone)  
on top of that people seem to have mixed feelings about it's process and 
workflows as well so deciding something like this behind closed door 
then simply announce it was not the right approach towards the community 
that is if the intend is truly to build,have and sustain a community but 
here we are.


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