I've submitted https://github.com/jenkinsci/jenkins/pull/6333 as the proposal to use the Linux installers based on `systemd`. Will submit a matching pull request to the packaging repository.
On Friday, March 4, 2022 at 12:53:38 PM UTC-7 Mark Waite wrote: > 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/716294fd-542a-4354-bfd9-370621095a05n%40googlegroups.com.
