services impact on startup times
by Chris Murphy
Hi,
These are based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso
in a VM. The numbers are different on bare metal but correlate.
The only standout is rngd.service. That's a pretty big single hit,
percentage wise. And I don't know if we even need it anymore. Among
the rest, perhaps atd.service and crond.service could be disabled by
default on new installations, in favor of systemd timers.
Startup finished in 1.320s (kernel) + 1.344s (initrd) + 7.727s
(userspace) = 10.392s
disable atd.service
Startup finished in 1.308s (kernel) + 1.310s (initrd) + 7.557s
(userspace) = 10.176s
disable dbxtool.service
Startup finished in 1.302s (kernel) + 1.291s (initrd) + 7.527s
(userspace) = 10.120s
disable import-state.service
Startup finished in 1.308s (kernel) + 1.326s (initrd) + 7.410s
(userspace) = 10.044s
disable iscsi.service
Startup finished in 1.316s (kernel) + 1.303s (initrd) + 7.177s
(userspace) = 9.797s
disable libvirtd.service
Startup finished in 1.316s (kernel) + 1.266s (initrd) + 6.779s
(userspace) = 9.361s
disable lvm2-monitor.service
Startup finished in 1.315s (kernel) + 1.323s (initrd) + 6.750s
(userspace) = 9.389s
disable mdmonitor.service
Startup finished in 1.316s (kernel) + 1.350s (initrd) + 6.675s
(userspace) = 9.342s
disable ModemManager.service
Startup finished in 1.270s (kernel) + 1.305s (initrd) + 7.052s
(userspace) = 9.629s
disable nfs-convert.service
Startup finished in 1.312s (kernel) + 1.343s (initrd) + 6.958s
(userspace) = 9.614s
disable rngd.service
Startup finished in 1.308s (kernel) + 1.277s (initrd) + 5.247s
(userspace) = 7.833s
disable switcheroo-control.service
Startup finished in 1.308s (kernel) + 1.334s (initrd) + 5.223s
(userspace) = 7.867s
disable vboxservice.service
Startup finished in 1.301s (kernel) + 1.302s (initrd) + 5.176s
(userspace) = 7.780s
disable crond.service
Startup finished in 1.310s (kernel) + 1.278s (initrd) + 5.076s
(userspace) = 7.665s
preset-all
Startup finished in 1.316s (kernel) + 1.312s (initrd) + 7.869s
(userspace) = 10.498s ##stopwatch 11.35
disable atd.service crond.service iscsi.service rngd.service vboxservice.service
Startup finished in 1.305s (kernel) + 1.294s (initrd) + 5.505s
(userspace) = 8.105s ##stopwatch 8.89
All of these times are based on 'systemd-analyze'. The stopwatch
method is less precise but still demonstrates the difference is real.
It may not be a big enough deal to do anything about it this cycle,
but could be something to look at for the next. Maybe more
opportunities are available.
--
Chris Murphy
3 years, 8 months
Re: Non-responsive maintainer: domcleal
by Robbie Harwood
"Dominic Cleal" <dominic(a)cleal.org> writes:
> Hi Robbie,
>
> On Tue, 1 Sep 2020, at 4:54 PM, Robbie Harwood wrote:
>> Hi, in accordance with [1] this is a non-responsive maintainer check for
>> Dominic Cleal.
>> [..]
>> So, does anyone know how to contact Dominic?
>
> You may remove me from these packages or orphan them as you see fit. I
> don't plan on making any more contributions.
Appreciate the prompt response, and thanks for your past work!
Thanks,
--Robbie
3 years, 8 months
Switching package to fragmented default configuration
by Miroslav Lichvar
I'm considering to split the default configuration file in the chrony
package to make it easier for vendors, products, and configuration
tools to override some specific settings (like the default NTP
servers) by dropping a file into a directory, instead of having to
modify a packaged config file. It seems to be a modern trend, used
by many packages in Fedora, and I have received some RFEs to adopt
in chrony.
The default /etc/chrony.conf would just have a single directive
loading configuration fragments from /etc/chrony.d and
/var/lib/chrony.d (and maybe also /var/run/chrony.d).
My concern is that it will basically break all existing tools that
need to check and/or modify the configuration (e.g. anaconda). They
will need to know the naming of the files which have specific settings
in order to override them, or implement a parser duplicating the
chronyd logic to figure out which files are loaded from where. Also,
I'm not sure how user-friendly this is for regular users who modify
the configuration manually.
Are there any recommendations for switching an existing single-config
package to a fully fragmented configuration? Is it worth the trouble,
or do you have any other suggestions?
Thanks,
--
Miroslav Lichvar
3 years, 8 months
Fedora Jam 33 Beta - Possible Blocker?
by Erich Eickmeyer
HI all,
Since the release of Koji 1.22, there has been a bug [1] blocking any
Fedora Jam 33 or Rawhide iso images from being spun. As you can imagine,
this is making me quite nervous. As it turns out, I'm waiting for Koji
1.22 to be released so that images can start building again. If this
isn't done in time for beta, then that means Fedora Jam will be unable
to participate in beta testing.
The issue in question is caused because Jam adds "threadirqs" as a boot
argument in addition to the normal boot arguments. This is a way to add
some low-latency characteristics to a kernel that isn't otherwise a
lowlatency kernel and is known to cut-down on xruns in audio production.
However, one question came up as to if threadirqs is a default in the
kernel configuration, but nobody could answer that. I was wondering if
anyone on this list knew?
I'm also going to be a little more intentional with working with the
pipewire developers on figuring out jack compatibility issues during the
F34 release cycle.
Thanks,
Erich
[1] https://pagure.io/koji/issue/2437
--
Erich Eickmeyer
Maintainer
Fedora Jam
3 years, 8 months
