I plan to submit a proposed pull request today to backport the systemd changes into the stable-2.332 branch. 2.335, 2.336, and 2.337 have all used the Jenkins Linux installer based on systemd. Issue reports have been rare and frequently related to misuse of files delivered by the package manager.
I hope the pull request will be a good point for discussion and approval. I don't feel there will be significantly broader testing by waiting 3 months before including the installer that uses systemd. Mark Waite On Thursday, February 24, 2022 at 5:13:13 PM UTC-7 [email protected] wrote: > While the System V init code from 2.333 and earlier is the least > likely to surprise us, it remains full of long-standing bugs > (including JENKINS-65809) and depends on third-party daemonization > packages, one of which is not available at all in Fedora EPEL 9. This > code has caused and continues to cause significant pain for users, and > this pain has increased in recent Debian and Red Hat-based > distributions. In my opinion, this code has outlived its usefulness. > > The systemd-based packaging first introduced in 2.335 has been > shipping for two weeks without issue. This code fixes a number of > long-standing bugs and improves integration between Jenkins and the > service manager. It also eliminates a number of fragile shell scripts > in favor of a declarative service configuration file. This should > prove easier to support in the unlikely case that there are issues. > Migration from the old configuration format is fully automated and has > been tested in a variety of configurations. > > The System V init code from 2.334 is a compromise between these > choices that, in my opinion, would please nobody. True, it addresses > the biggest deficiencies of the old implementation, including > JENKINS-65809 and the Fedora EPEL 9 issue. Yet, it has been tested the > least (only one week) and retains a number of existing issues. Because > of its reliance on fragile shell scripts, this code is difficult to > support. If there are issues with it, the arduous task of supporting > users would end up being throwaway work, as the entire implementation > has changed in later releases with the introduction of systemd > support. > > For these reasons, my vote is to backport the systemd code to 2.332.1 > LTS. Although this does not meet the usual criteria for backports, I > believe that the benefits mentioned above outweigh the risks. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/81c60a9c-25ab-424c-9caf-1e73b9313cd4n%40googlegroups.com.
