I'm not a systemd maintainer, but maybe this is a good place to suggest opening a pull request against systemd's Pagure repo
https://src.fedoraproject.org/rpms/systemd/branch/f27
with the patch?
Looking at the issue, there seems to be different information regarding how much would need to be patched.

That said, I think it's worth separating the bug listed from the statement that "systemd is abandonware". For the latter case, I suggest offering a bit more data. On the f27 branch linked above I see a commit with patches 3 months ago.

@dperpeet in the past 3 fedora releases i reported enough systemd bugs with serious regressions which did not get fixed in the whole lifecycle of the Fedora release - especially when even patches are available this is unacceptable - and no, upgrade to the next fedora release to get one bug fixed and three new ones introduced is no solution

either upstream is broken because of missing minors or when upstream speaks the truth that there is a tree with patches for downstream distributions Fedora does a terrible job for years now

however, an issue leading to unclean unmount of filesystems at shutdown is a bug-type where normally everybody sane in his mind would stop whatever he is doing and get that fixed as soon as possible because silent data loss is the worst thing you can have on a system

@hreindl Thank you for reporting the issues!

It looks like @jsynacek merged the fix earlier.

Looking to the future, we're currently working on leveraging the systemd CI in Fedora CI. With upstream tests and Fedora tests linked together, we should see these fixes being merged in a more controlled manner.

@dperpeet in the past 3 fedora releases i reported enough systemd bugs with serious regressions which did not get fixed in the whole lifecycle of the Fedora release - especially when even patches are available this is unacceptable - and no, upgrade to the next fedora release to get one bug fixed and three new ones introduced is no solution

This is sad. It is unacceptable that you raise this to FESCo only after the fact, especially when patches werre available and you could easily create a pull request, do scratch build and test them and ask FESCo or a proven packager to apply the PRs. And no, opening a FESCo ticket after the releases are EOL or the patches are already merged is no solution.

IMHO there is nothing for FESCo to do at the moment.

@till besides that you trageted the wrong person with oyur last comment

the issue that systemd bugreports even with patches mentiond there are ignored and not fixed until the release goes EOL is not just about that single bug or only F27 and i asked the project leader in a private mail how to get that solved

given that systemd is a core-component this is a problem for the distribution at a whole

the FESCO-ticket was opened before the patch where applied and no ican't do scratch builds but i installd one (but a newer systemd version cmpiled for F27) long ago and gave feedback that it solves the issue and then nothing happened - people have now 4 weeks time to upgrade to F27 and please don't tell me the issue would have itself resolvd magically

"opening a FESCo ticket after the releases are EOL is no solution" - no, and hence i opened the ticket BEFORE F27 goes EOL and before get forced update production machines with a known bug leading to data loss when F26 is EOL

the issue that systemd bugreports even with patches mentiond there are ignored and not fixed until the release goes EOL is not just about that single bug or only F27 and i asked the project leader in a private mail how to get that solved

Bug https://bugzilla.redhat.com/show_bug.cgi?id=1554943#c13 got an update for F27 less than 24 hours after the one line patch was mentioned there. This is pretty fast. So this is not an example for patches being ignored. Also in your initial comment your write

how can it be that the most important component after the kernel is left over moths with bugs which easily lead to data loss?

But the bug you presented is less than two months old.

the FESCO-ticket was opened before the patch where applied and no ican't do scratch builds but i installd one (but a newer systemd version cmpiled for F27) long ago and gave feedback that it solves the issue and then nothing happened - people have now 4 weeks time to upgrade to F27 and please don't tell me the issue would have itself resolvd magically

I just tell you that if you would like issues to be fixed in a timely manner, you need to escalate them when there is still time to handle them. You complain a lot about unnamed bugs in old EOL releases that nobody can do anything about. I do not care about this and you are just wasting time with these complaints. If there is an issue in the future with a patch that needs to be applied, just file a PR, wait a reasonable amount of time for the maintainer to apply it and then you can escalate this. Then we can apply the patch and everyone is happy. Your current behavior is not constructive and your tone is also not friendly, therefore you are not making things better.

"opening a FESCo ticket after the releases are EOL is no solution" - no, and hence i opened the ticket BEFORE F27 goes EOL and before get forced update production machines with a known bug leading to data loss when F26 is EOL

Since there is now an update for F27 there is nothing left to do.

@til you still don't get it - "got an update for F27 less than 24 hours after the one line patch was mentioned there" - yes BECAUSE of the Ticket here, because i mentioned the bug on the LKML and brought it to attention - and it was NOT donme by the maintainer which said "OK, I'll try to backport this to F27" - do you guy still not realize that he is a SYSTEMD-UPSTREAM MAINTAINER

it's a REPEATING PROBLEM over many fedora releases now and just sit sit here and close your eyes and tell USERS they should file pull-requests - WTF - and then you expect them to be friendly when they feel like talking with blind people about colors?

"If there is an issue in the future with a patch that needs to be applied, just file a PR" - damned i can't file a PR - the issue is that a) such bugs make it regulary to releases and b) then are handeled badly beause c) it's a shitty upstream with no point releases and d) the promised "here distributions can cherry pick" obviously don't work

any other software on this planet has bugfix releases - so either maintain and fix it properly, update systemd more often if nobody is able to maintain it in the shape it is or convince upstream that they need for downstream useable release management

"But the bug you presented is less than two months old" - seriously: WTF - a bug which can lead to data loss normally should trigger a red flag and responsible people won't go to sleep until it's fixed and a update available - don't play the volunteers card in that context!

it would have taken another 2 months without raisning altrt flags on differnt channels and THEN? upgrade production servers to a known broken distribution or leave them vulnerbale? what irresponsible attitude but well, all volunteers, than eating your data must be fine

remove that stupid graphical crap for boot/shutdown and at least this bug would have been faced probably before the F27 release, at this pointin time you don't get anything into logs and so people just wonmder why there machines boot randomlywith a fsck

@til and what you finally dont grasp is that the fix https://github.com/systemd/systemd/issues/6796 is from 2017-09-11 while 2017-11-14 was Fedora 27 Final Release - and you still pretend there is no problem on the Fedora side?

it's a REPEATING PROBLEM over many fedora releases now and just sit sit here and close your eyes and tell USERS they should file pull-requests - WTF - and then you expect them to be friendly when they feel like talking with blind people about colors?

@hreindl your attitude is a repeating problem and I expect you to be friendly no matter what. There is no excuse for being unfriendly here and I hope you are not serious about someone being disabled being a valid excuse for you to be rude.

@hreindl Sorry. I was aware of the bug, and I knew it was important to you, but I just didn't have enough time to work on it. I wasn't aware of that the small patch fixes the problem, and I expected that a bigger chunk of time will be needed to backport the patches. Fortunately, Alan Jenkins noticed the fix and Jan Synacek rebuilt the rpm. Once the simple fix was available, it was pushed out pretty quickly.

The bigger picture is that this bug is just one of tens of complicated bugs that are opened against systemd in each release (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1557655, various unfathomable errors which turn out to be selinux issues, etc), and the number of people working on them is very limited. So unless more volunteers step up, we'll continue to have important systemd bugs languishing.

I appreciate the testing that you do and the bug reports. I really do. But even then, this doesn't mean that we have the maintainer resources to find a resolution. If you or somebody else wants to move things forward, opening a PR with a fix is the best solution. Diagnosing the issue down to an upstream commit that fixes the issue is also great. Triaging some other bugs would also be nice. Opening yet another ticket to discuss existing tickets — not so much.

my real problem are things like below while https://github.com/systemd/systemd/issues/3867 existed and the bug was present the whole lifetimeof F25

-------- Weitergeleitete Nachricht --------
Betreff: Re: [systemd-devel] F25: NAMESPACE spawning: Too many levels of symbolic links
Datum: Thu, 16 Mar 2017 19:06:11 +0100
Von: Reindl Harald h.reindl@thelounge.net
An: Mailing-List systemd systemd-devel@lists.freedesktop.org

Am 16.03.2017 um 18:21 schrieb Michal Sekletar:

Is any of inaccessible directories actually symlink? If so then I
believe you are hitting,

yes - /data on this machine while it's on others sharing that unit a physical directory

https://github.com/systemd/systemd/issues/3867

This is fixed upstream, but patches for this were not backported to
Fedora 25 yet. Here are Fedora bugs mentioning similar symptoms,

https://bugzilla.redhat.com/show_bug.cgi?id=1399991
https://bugzilla.redhat.com/show_bug.cgi?id=1414157

I've also emailed him multiple times over the years asking him to not make personal attacks. He's unable to keep to that and that's why he's not been reinstated on the lists. I just got the following from him:

And Harald: seriously. This is not how we conduct discussion in Fedora

pretending that there is no difference between just drop a file to a
folder or also edit a config file at the same time to make it effective
is by definition bullshit - it's that easy

Fedora has a big problem: too much people waste to much time for making
things worsers - the idiot discussion about the boot menu as example -
guess how i learned that i can boot into the old kernel? not by reading
soem docs, just by face the menu - but hey, new users have too see a
windows-look-alike....