Re: Whole system analysis with frame pointers
On Sat, Oct 21, 2023 at 3:06 PM Richard W.M. Jones wrote: > I was asked about the topic in the subject, and I think it's not very > well known. The news is that since Fedora 38, whole system > performance analysis is now easy to do. This can be used to identify > hot spots in single applications, or what the (whole computer) is > really doing during lengthy operations. > > You can visualise these in various ways - my favourite is Brendan > Gregg's Flame Graphs tools, but perf has many alternate ways to > capture and display the data: > > https://www.brendangregg.com/linuxperf.html > https://www.brendangregg.com/flamegraphs.html > https://perf.wiki.kernel.org/index.php/Tutorial > > I did a 15 min talk on this topic, actually to an internal Red Hat > audience, but I guess it's fine to open it up to everyone: > > http://oirase.annexia.org/tmp/2023-03-08-flamegraphs.mp4 [57M, 15m41s] Hello Richard, Thank you for posting this. In the talk you mentioned that the "--off-cpu" option was not yet available. Has there been any progress to enable it since the talk was recorded? I have just tried it in Rawhide. perf is still built without it: Warning: option `off-cpu' is being ignored because no BUILD_BPF_SKEL=1 What is blocking the enablement of this feature? Are there some trade-offs? Is there a thread or a Bugzilla ticket where it is discussed? Michal > To show the kind of thing which is possible I have captured three > whole system flame graphs. First comes from doing "make -j32" in the > qemu build tree: > > http://oirase.annexia.org/tmp/2023-gcc-with-lto.svg > > 8% of the time is spent running the assembler. I seem to recall that > Clang uses a different approach of integrating the assembler into the > compiler and I guess it probably avoids most of that overhead. > > The second is an rpmbuild of the Fedora Rawhide kernel package: > > http://oirase.annexia.org/tmp/2023-kernel-build.svg > > I think it's interesting that 6% of the time is spent compressing the > RPMs, and another 6% running pahole (debuginfo generation?) But the > most surprising thing is it appears 42% of the time is spent just > parsing C code [if I'm reading that right, I actually can't believe > parsing takes so much time]. If true there must be opportunities to > optimize things here. > > Captures work across userspace and kernel code, as shown in the third > example which is a KVM (ie. hardware assisted) virtual machine doing > some highly parallel work inside: > > http://oirase.annexia.org/tmp/2023-kvm-build.svg > > You can clearly see the 8 virtual (guest) CPUs on the left side, using > KVM. More interesting is that this guest uses a qcow2 file for disk > and there's a heck of an overhead writing to that file. There's > nothing to fix here -- qcow2 files shouldn't be used in this > situation; for best performance it would be better to use a local > block device to back the guest. > > > The overhead of frame pointers in my measurements is about 1%, so this > enhanced visibility into the system seems well worthwhile. I use this > all the time. This year I've used it to suggest optimizations in > qemu, nbdkit and the kernel. > > Rich. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Unretire rshim
Hello, I intend to unretire the 'rshim' package: https://src.fedoraproject.org/rpms/rshim The package is needed in RHEL. Upstream is active. The latest tagged release was just 2 months ago. Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dynamic preemption support in Linux 5.12 kernel
On Mon, Apr 26, 2021 at 3:31 AM Chris Murphy wrote: > On Sun, Apr 25, 2021 at 12:39 PM Artem Tim wrote: > > Upcoming 5.12 allow building with dynamic preemption support which > allows changing mode at boot/run-time so finally no need to rebuild or make > alternative kernel build anymore[1]. Responsive system is a must have for > gaming and good desktop experience overall, not only for professional > audio. For example difference in input mouse lag is like day and night with > PREEMPT mode. Maybe on cheap mouse this is hard to notice but on 500-1000Hz > mouse really easy. You can test this yourself with experimental kernel > build on COPR[2]. Some Linux distros[3] already using PREEMPT mode by > default for a decent period of time. Fedora kernel build with > CONFIG_PREEMPT_VOLUNTARY but this is not enough for desktop use case. > > > > Please provide full PREEMPT mode by default in 5.12 kernel for desktop > variants. With 5.12 it is possible for user to change it without efforts if > they need this. > > > > I see CONFIG_HAVE_PREEMPT_DYNAMIC=y with kernel > 5.12.0-0.rc8.191.fc35.x86_64+debug. > CONFIG_HAVE_PREEMPT_DYNAMIC only says the architecture supports the feature. This is hard-coded by arch/x86/Kconfig. To actually enable the feature, CONFIG_PREEMPT=y would have to be set. The combination of CONFIG_PREEMPT and CONFIG_HAVE_PREEMPT_DYNAMIC then selects CONFIG_PREEMPT_DYNAMIC. See kernel/Kconfig.preempt. Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: System freezes randomly - need to reboot
On 1/14/19 1:31 PM, arnaud gaboury wrote: > Hello everyone, > > ## > $ cat /etc/os-release > NAME=Fedora > VERSION="29.20181230.0 (Workstation Edition)" > ID=fedora > VERSION_ID=29 > VERSION_CODENAME="" > PLATFORM_ID="platform:f29" > PRETTY_NAME="Fedora 29.20181230.0 (Workstation Edition)" > > VARIANT="Workstation Edition" > VARIANT_ID=workstation > OSTREE_VERSION=29.20181230.0 > ### > > Wayland with Gnome session > > My system freezes randomly and I need to reboot. I can't spot any specific > action or app that could trigger the freeze, as it happens with my regular > app open: Gnome terminal, Firefox, Telegram desktop. When running the > following command,I get some hints: > > ### > $ journalctl --system > . > Jan 14 09:04:51 yogabx audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 > ses=4294967295 msg='unit=systemd-coredump@3-3825-0 comm="systemd" > exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=succes> > Jan 14 09:04:51 yogabx systemd-coredump[3826]: Process 3819 (fwupd) of user 0 > dumped core. > > Stack trace of thread 3819: > #0 0x7f549d033f42 > __strcmp_avx2 (libc.so.6) > #1 0x7f549d3f43e5 n/a > (libgio-2.0.so.0) > #2 0x7f549d3f547f > g_unix_is_mount_path_system_internal (libgio-2.0.so.0) > #3 0x7f549d3f56e8 n/a > (libgio-2.0.so.0) > #4 0x7f549d3f5b07 > g_unix_mount_at (libgio-2.0.so.0) > #5 0x7f548c9272f7 > fu_plugin_coldplug (libfu_plugin_uefi.so) > #6 0x557cbc21f550 > fu_plugin_runner_coldplug (fwupd) > #7 0x557cbc206a98 n/a > (fwupd) > #8 0x557cbc20f7fa > fu_engine_load (fwupd) > #9 0x557cbc1ff55a main > (fwupd) > #10 0x7f549cefb413 > __libc_start_main (libc.so.6) > #11 0x557cbc1ff86e _start > (fwupd) > > Stack trace of thread 3821: > #0 0x7f549cfc9421 __poll > (libc.so.6) > #1 0x7f549c820d5f n/a > (libusb-1.0.so.0) > #2 0x7f549d0a558e > start_thread (libpthread.so.0) > #3 0x7f549cfd46a3 __clone > (libc.so.6) > > Stack trace of thread 3823: > #0 0x7f549cfc9421 __poll > (libc.so.6) > #1 0x7f549d5033a6 n/a > (libglib-2.0.so.0) > #2 0x7f549d503762 > g_main_loop_run (libglib-2.0.so.0) > #3 0x7f549d3ca10a n/a > (libgio-2.0.so.0) > #4 0x7f549d52c2aa n/a > (libglib-2.0.so.0) > #5 0x7f549d0a558e > start_thread (libpthread.so.0) > #6 0x7f549cfd46a3 __clone > (libc.so.6) > > Stack trace of thread 3820: > #0 0x7f549cfc9421 __poll > (libc.so.6) > #1 0x7f549d5033a6 n/a > (libglib-2.0.so.0) > #2 0x7f549d5034d0 > g_main_context_iteration (libglib-2.0.so.0) > #3 0x7f549d503521 n/a > (libglib-2.0.so.0) > #4 0x7f549d52c2aa n/a > (libglib-2.0.so.0) > #5 0x7f549d0a558e > start_thread (libpthread.so.0) > #6 0x7f549cfd46a3 __clone > (libc.so.6) > > Stack trace of thread 3822: > #0 0x7f549cfc9421 __poll > (libc.so.6) > #1 0x7f549c81a495 n/a > (libusb-1.0.so.0) >
orphaned ath_info
Hello, I orphaned ath_info, a tool to read and write EEPROM on Atheros wireless cards. It only worked with ath5k cards, which I no longer have. Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: remote X connections
On 12/01/2017 04:44 PM, Christian Groessler wrote: > On 11/30/17 13:57, Michal Schmidt wrote: > >> Looks like gdm is missing BuildRequires: pkgconfig(xorg-server) >> Please report a bug for gdm in Bugzilla. > > > Can I cite your email on this bug report. What exactly will this > "BuildRequires" change accomplish? No need to file the bugreport. Ray Strode already fixed it. The added BuildRequires ensures the correct package is installed in the buildroot to make the pkg-config test in gdm's configure.ac work. Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: remote X connections
On 11/30/2017 01:39 PM, Christian Groessler wrote: > This is handled by conditional compilation in gdm (depending on a > HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY define). > > The setting for this define is determined in configure.ac, lines[...] > if $PKG_CONFIG --atleast-version=1.17 xorg-server; then > AC_DEFINE([HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY], [], [XServer > disables tcp access by default]) fi[...] > On my system, running the test above returns correct results: > > $ pkg-config --atleast-version=1.17 xorg-server ; echo $? 0 $ > > > I've build the gdm RPM from source on my local machine, installed it, > and, hey, now everything works as expected. > > So I guess that the machine used to build the official packages still > has an old X server installed. If that's true, could this be fixed? Looks like gdm is missing BuildRequires: pkgconfig(xorg-server) Please report a bug for gdm in Bugzilla. Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: f26->f27 server upgrade, starting system activity accounting tool every 10 minutes
On 11/13/2017 12:09 AM, Chris Murphy wrote: > There's still the issue of creating/removing slice User Slice of pcp, > and the Starting/Stopping User Manager fo UID 989 that keeps > happening. Those are triggered by cron jobs in the "pcp" package: /etc/cron.d/pcp-pmie /etc/cron.d/pcp-pmlogger Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: static builds for user emulators in Fedora QEMU RPMs
On 06/29/2016 12:03 PM, Daniel P. Berrange wrote: > The change to introduce a qemu-binfmt package has small upgrade > implications since anyone with qemu-user installed today, will loose > the binary format rules unless they manually install qemu-binfmt. Not if you add "Obsoletes: qemu-user < V-R" (where V-R is the first version-release that contains this change) to both qemu-binfmt and qemu-user. Michal -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On 05/27/2016 11:51 AM, Dominique Martinet wrote: > Just noticed this change on rawhide... > https://github.com/systemd/systemd/blob/master/NEWS#L29 > * systemd-logind will now by default terminate user processes that are > part of the user session scope unit (session-XX.scope) when the user > logs out. This behavior is controlled by the KillUserProcesses= > setting in logind.conf, and the previous default of "no" is now > changed to "yes". This means that user sessions will be properly > cleaned up after, but additional steps are necessary to allow > intentionally long-running processes to survive logout. > > While the user is logged in at least once, user@.service is running, > and any service that should survive the end of any individual login > session can be started at a user service or scope using systemd-run. > systemd-run(1) man page has been extended with an example which shows > how to run screen in a scope unit underneath user@.service. The same > command works for tmux. > > After the user logs out of all sessions, user@.service will be > terminated too, by default, unless the user has "lingering" enabled. > To effectively allow users to run long-term tasks even if they are > logged out, lingering must be enabled for them. See loginctl(1) for > details. The default polkit policy was modified to allow users to > set lingering for themselves without authentication. > > Previous defaults can be restored at compile time by the > --without-kill-user-processes option to "configure". ... > I did not see any discussion about this particular setting in the > systemd-devel mailing list The commit that made the change: https://github.com/systemd/systemd/commit/97e5530cf20 referenced two bugreports: https://bugs.freedesktop.org/show_bug.cgi?id=94508 https://github.com/systemd/systemd/issues/2900 Michal -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
On 01/11/2016 03:48 PM, Reindl Harald wrote: > Am 11.01.2016 um 15:37 schrieb Michal Schmidt: >> On 01/11/2016 02:58 PM, Reindl Harald wrote: >>> *nothing* needs a PID file path because systemd knows the main-PID >>> since it's a supervisor >> >> systemd cannot always guess which PID is the main PID of the service, >> so with Type=forking it's good to use PIDFile= > > every service in the last years which logged warnings about PIDFile > while working fine was fixed here by remove that line Good for you. > the main PID is the PID after the double-fork Some programs exit() the original process immediately after the first fork(). Then it's possible for systemd to observe the first child and assume it is the main PID. That's bad because that process is going to go away after forking the second time. Michal -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
On 01/11/2016 02:58 PM, Reindl Harald wrote: > Am 11.01.2016 um 14:32 schrieb Muayyad AlSadi: >>> "Type=forking" implies that depending services are started >>> *after* the forking and the service is *really* read (it needs >>> depending on the signatures a longer time for initalization) >> >> but I guess it needs a PID file path to work properly which is not >> the case > > *nothing* needs a PID file path because systemd knows the main-PID > since it's a supervisor systemd cannot always guess which PID is the main PID of the service, so with Type=forking it's good to use PIDFile=. Michal -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf replacing yum and dnf-yum
On 04/08/2015 08:41 AM, Jan Zelený wrote: On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote: On 04/07/2015 05:07 PM, Kevin Fenzi wrote: dnf's default behavior is like yum with --skip-broken already. WHAT? --skip-broken is a band-aid to work around packaging mistakes and bugs and NOT be the default. IMO, this kind of behavior is not helpful and therefore should be reverted. This behavior is actually helpful, as it doesn't bother users with a bunch of broken deps messages they usually don't fully understand (check out how many of these bugs were filed against yum over the years). Putting the opinion of myself and the dnf team aside, I'd like to point out that the information you want is still available - dnf check-update will show you all the updates, even those that have broken deps. Running this command right after dnf upgrade will list you those that could not be installed. Would it please be possible for dnf update to print this information automatically? E.g. apt-get can say The following packages have been kept back: ... dnf could report it like in this mockup: ... Dependencies resolved. PackageArch VersionRepository Size Upgrading: emacs x86_64 1:24.4-6.fc21 updates-testing 3.0 M emacs-common x86_64 1:24.4-6.fc21 updates-testing37 M emacs-filesystem noarch 1:24.4-6.fc21 updates-testing64 k Skipping for dependency reasons: firefoxx86_64 37.0.1-1.fc21 updates-testing69 M Transaction Summary Upgrade 3 Packages Skip 1 Package Total download size: ... Is this ok [y/N]: Thanks, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Issue with yum/systemd?
On 03/10/2015 03:13 AM, Dave Johansen wrote: #0 0xb76debac in __kernel_vsyscall () #1 0xb7510d03 in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0xb6fa4842 in rpmScriptRun () from /lib/librpm.so.3 #3 0xb6f83c53 in runScript () from /lib/librpm.so.3 #4 0xb6f8434f in runInstScript () from /lib/librpm.so.3 #5 0xb6f8531b in rpmpsmRun () from /lib/librpm.so.3 #6 0xb6f9a3cb in rpmteProcess () from /lib/librpm.so.3 #7 0xb6fa1714 in rpmtsRun () from /lib/librpm.so.3 [...] It looks like yum is waiting on some process. It's waiting for a package scriptlet to finish. Is there a way I can tell what the process is and why it hasn't returned yet? Any other ideas on how I can figure out what is going wrong? You need to look for the child processes of yum and see what they're doing. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why sysrq is limited to only sync command on official fedora kernel?
On 02/25/2015 03:04 PM, Josh Boyer wrote: On Wed, Feb 25, 2015 at 8:54 AM, Ali AlipourR alipoo...@gmail.com wrote: Hi, Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, The file in /usr will be overwritten by the next package update. create your own in /etc/sysctl.d/, Yes, local configuration belongs to /etc. See also man sysctl.d. or (as root) set it to whatever you would like via /proc/sys/kernel/sysrq. Or pass sysrq_always_enabled on the kernel command line. sysrq_always_enabled [KNL] Ignore sysrq setting - this boot parameter will neutralize any effect of /proc/sys/kernel/sysrq. Useful for debugging. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why sysrq is limited to only sync command on official fedora kernel?
On 02/25/2015 03:43 PM, Josh Boyer wrote: On Wed, Feb 25, 2015 at 9:35 AM, Ali AlipourR alipoo...@gmail.com wrote: Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, create your own in /etc/sysctrl.d/, or (as root) set it to whatever you would like via /proc/sys/kernel/sysrq. Of course it can be changed at runtime, but I mean why official fedora kernel shouldn't be configured to allow all (or at least a wider subset) of sysrq commands by default? Maybe we're getting hung up on a terminology issue, but this isn't a kernel configuration issue. It's something userspace is doing. This way official fedora live CDs are unsuitable for system recovery tasks; you have to change sysrq value every time you use live CDs or build your own live CD. That's a good point. Since the live images have a rescue mode, maybe there is a way to use a different value when booted into that. How that would look, I'm not sure. Maybe dracut would need to include an override file in the initramfs. I don't follow the reasoning. Why am I more likely to need SysRq in rescue mode than in normal boot? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: %{_unitdir} no longer defined in Rawhide
Dne 5.2.2015 v 14:05 Richard W.M. Jones napsal:
Somehow:
RPM build errors:
File must begin with /: %{_unitdir}/guestfsd.service
It seems like _unitdir is no longer defined.
Is this a bug? And in what package - my package or systemd?
I checked the systemd commit log in Fedora and there's no mention of
_unitdir or anything I can find.
Looks like it's accidental breakage in:
http://pkgs.fedoraproject.org/cgit/systemd.git/commit/?id=c90404b6483813ef06f80f525047cb4df785aa44
Cleanup up spec file a bit
Will fix.
Thanks,
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 02:47 AM, Matthew Miller wrote: Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job sysinit.target/start Matthew, are you showing only messages at loglevel warning and higher? Because in between these two lines I'd expect to see some Found dependency on service/job_type at loglevel info. Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 12:57 PM, Matthew Miller wrote: Oct 31 07:42:29 ubik systemd[1]: Found ordering cycle on basic.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on sysinit.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-update-utmp.service/verify-active Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-tmpfiles-setup.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-journal-flush.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs-pre.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on nfs-client.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on gssproxy.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on basic.target/start Oct 31 07:42:29 ubik systemd[1]: Breaking ordering cycle by deleting job systemd-update-utmp.service/verify-active This ordering cycle was introduced recently by changes in nfs-utils's unit files when nfs-client.target got an After dependency on gssproxy. nfs-client.target wants to be started before any remote filesystems are mounted (which is before basic.target). gssproxy.service has default dependencies, so it wants to start quite late during boot (after basic.target). [CC Steve.] Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 02:03 PM, Matthew Miller wrote: On Fri, Oct 31, 2014 at 01:44:27PM +0100, Michal Schmidt wrote: This ordering cycle was introduced recently by changes in nfs-utils's unit files when nfs-client.target got an After dependency on gssproxy. Are you sure? Looks like I last updated nfs-utils on Oct 26th, and I've rebooted several times since then without incident — it's only after this last update that the problem occured. I mean, I believe you that this is a problem, but did something else change too? Maybe you already had an ordering cycle on Oct 26, but different units were chosen for deletion when breaking the cycle, and by luck it had fewer directly observable consequences. Could you check older logs for ordering cycles? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 02:30 PM, Matthew Miller wrote: Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount: Directory /dev/mqueue to mount over is not empty, mounting anyway. Oct 31 09:19:46 ubik mount[4484]: mount: mount point /dev/mqueue does not exist Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount mount process exited, code=exited status=32 Oct 31 09:19:46 ubik systemd[1]: Failed to mount POSIX Message Queue File System. I saw this too, but didn't look into it. On a related but different note — is there a way to detect potential ordering cycles from a set of RPMs on disk (possibly installed in a chroot or something) _without_ actually booting? Maybe we could add a taskotron check for that for packages with changes to systemd unit files. (I realize that what is enabled on people's systems will have an impact, but we could check against a set of defaults at least.) It's not the perfect solution, but this command would report the cycle you saw: /usr/lib/systemd/systemd --test --system Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@0pointer.de wrote: So the problem appears to be that gssproxy.service been ordered before remote-fs-pre.target. That target is ordered before basic.target. However gssproxy.service also is ordered after basic.target (simply because all services by default are ordered before basic.target, unless they explicitly specify DefaultDependencies=no), hence there's an ordering cycle. Most likely some NFS maintainers tried to move gss-proxy.service into the early boot, and didn't set DefaultDependencies=no. That said, services running in early boot must be written in a specific style (i.e. not assume /var to be around, and suchlike), I do wonder if gssproxy is ready for that. Anyway, long story short: file a bug against the gssproxy package. I don't think this explains all the problems folks are having with systemd-217. I wonder if the new ordering dependency between systemd-journal-flush.service and systemd-tmpfiles-setup.service (added in 74055aa76 journalctl: add new --flush command and make use of it in systemd-journal-flush.service) participates in the ordering cycles. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 04:57 PM, Igor Gnatenko wrote: systemd-logind: failed to get session: PID 879 doesnt belong to any known session That's not necessarily related to the problem. I have this message in the log even when gdm works fine. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Anyone know how to get rsyslog to not use journald but to listen on /dev/log again.
On 09/10/2014 02:10 PM, Daniel J Walsh wrote: We need this for running rsyslog within a docker container where systemd/journald might not be running. In /etc/rsyslog.conf remove $ModLoad imjournal, set $OmitLocalLogging to off and make sure $ModLoad imuxsock is present. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
On 09/04/2014 05:11 PM, Sérgio Basto wrote: OTOH , the support of systemd is not good, we got bug opened and they are ignored as nothing happens, as for example bug https://bugzilla.redhat.com/show_bug.cgi?id=1088619 The bug is unresolved so far, but it is not ignored. At least there is a known workaround. BTW, the boycott site is not new. I remember reading it during or maybe shortly after the Debian init war. I won't bother explaining the misconceptions. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: /media - /run/media???
On 08/14/2014 12:17 PM, Matthew Miller wrote: On Thu, Aug 14, 2014 at 10:06:11AM +0200, Ondrej Vasik wrote: Actually I'm going to revert the /media - /run/media change. The above sentence is unfortunately ambiguous. It is really not solving the issue it was trying to help with and in addition it might be fragile in some cases. Sorry for the noise. H... that should probablt be run through the change process... it needs release notes at least! No, I'm sure Ondřej only meant that he'd revert the replacement of the /media directory with a symlink to /run/media, which was in Rawhide for only two weeks or so. He does not intend to change the path where removable media get mounted. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On 07/10/2014 04:34 PM, Stephen Gallagher wrote: Basically, in order to swap out the productized and non-productized release packages, it's not actually as simple as 'yum swap fedora-release-standard fedora-release-server'. The way the dependency processing works in yum and dnf will generally fall over and fail to properly detect the other packages that would need to be swapped (such as firewalld-config-standard - firewalld-config-server). dnf seems able to figure out even the firewalld-config-* swap fine: $ sudo dnf install fedora-release-workstation --allowerasing Dependencies resolved. Package Arch Version Repository Size Installing: fedora-release-workstation noarch21-0.9 rawhide 17 k firewalld-config-workstationnoarch0.3.10-4.fc21 rawhide 40 k Removing: fedora-release-server noarch21-0.9 @System1.0 k firewalld-config-server noarch0.3.10-4.fc21 @System1.0 k Transaction Summary Install 2 Packages Remove 2 Packages Total download size: 57 k Is this ok [y/N]: ... Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.5.3 and dnf-core-plugins-0.1.1 released
On 07/03/2014 12:04 PM, Reindl Harald wrote: dnf remove python ends in remove dnf and yum too as weel as dnf remove kernel still offers to remove both protected_packages.py is missing from the package. Looks like an upstream bug - it's not referenced in plugins/CMakeLists.txt Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.5.3 and dnf-core-plugins-0.1.1 released
On 07/03/2014 01:45 PM, Reindl Harald wrote: BTW: how do we handle the protection for systemd which is in case of YUM provided by the systemd package but DNF is not mandatory in F21 - so /etc/dnf/protected.d/ is only conditional available The dnf plugins looks at /etc/yum/protected.d/ too, so we can just leave systemd's dropin file where it is now. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: trimming down Fedora installed size
On 04/09/2014 09:33 AM, Marius A wrote: 3. cleanup /var/log/journal, which seems it's not automatically rotated It's supposed to be automatic. How big did it become on your system? If the default size limits do not suit you, you can change them in /etc/systemd/journald.conf. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/04/2014 04:15 PM, Mikolaj Izdebski wrote: Compression of payload.tar -- command| real | user | sys | memory | compr. size ---+++--++ lbzip2 | 3.36 | 170.07 | 6.38 | 380448 | 424676188 lbzip2 -u | 6.45 | 123.14 | 3.80 | 255524 | 424518771 pbzip2 | 6.78 | 288.33 | 8.90 | 491644 | 425213134 bzip2 | 176.68 | 175.76 | 0.67 | 8000 | 425108407 Conclusions === [...] lbzip2 -u always produced smallest files (even smaller than bzip2) while consuming the least amount of resources (CPU power and memory). The table above says it needs about 30 times *more* memory than bzip2. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Considering GNOME 3.12 as an F20 update
On 04/04/2014 05:40 PM, Jiri Eischmann wrote: First after the upgrade I didn't even boot to GDM. Too bad I didn't debug it because I had already been considering a clean install, so I did it right away. My setup was not typical, I had been upgrading since F15. But apparently I was not the only one. One guy on the forum complained about a very similar problem. He blames i686 packages and their dependencies which might have been my problem as well because due to Steam I also had a lot from the graphics stack installed in i686 versions. I had the same problem. It turned out I was missing the glib2 package update from the COPR. The reason was that I had both glib2.x86_64 and glib2.i686 installed, but I only enabled the x86_64 COPR. dnf silently skipped updating the package due to this problem. Gnome shell was crashing with: gnome-session[1722]: (gnome-shell:1876): Gjs-WARNING **: JS ERROR: Error: No property 'gi' in importer (or its value was undefined) gnome-session[1722]: _init@resource:///org/gnome/gjs/modules/overrides/GLib.js:258 gnome-session[1722]: @resource:///org/gnome/shell/ui/environment.js:3 gnome-session[1722]: @main:1 gnome-session[1722]: gnome-session[1722]: WARNING: Application 'gnome-shell.desktop' killed by signal 11 Perhaps a versioned dependency on glib2 would be worth adding somewhere, but anyway I would not see this problem if this were a normal Fedora update, because then I'd get the package for both archs. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DSO API stability guidelines
On 03/21/2014 01:18 PM, Neil Horman wrote: Can anyone point me to fedora packaging documentation that discusses the need for API stability in packaged shared libraries? I'm sure we have some requirement that APIs in a DSO need to be versioned and maintained through a release, but for the life of me I'm unable to find it. Hi Neil, The Updates Policy for stable releases (http://fedoraproject.org/wiki/Updates_Policy#Stable_Releases) says this about ABIs, APIs: ABI changes in general are very strongly discouraged, they force larger update sets on users and they make life difficult for third-party packagers. [...] Package maintainers MUST: Avoid Major version updates, ABI breakage or API changes if at all possible. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SystemD service stop behavior
On 10/23/2013 04:09 PM, Michael Cronenworth wrote: Should systemctl stop foo.service stop all parent and child service processes? systemd allows this to be configured in the service's unit file. See man systemd.kill. glusterd.service uses KillMode=process. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd journal interaction with btrfs, unfixable corruption
On 09/25/2013 06:35 AM, Chris Murphy wrote: There are some reports of VM images on btrfs being corrupted somehow (although I don't think it's related to balance, I could be wrong), and the solution is to set VM images to nodatacow. So I wonder if there's some behavior of systemd journaling that's similar? I don't know about VM images, but systemd-journald writes to journal files using a bunch of writable mmap windows. It also calls ftruncate to truncate a journal file to its current size, just to trigger inotify clients that are watching for changes in the file. Sometimes it calls fsync. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why is AHCI built-in?
On 08/28/2013 12:46 AM, poma wrote: On 19.08.2013 20:46, Kyle McMartin wrote: On Mon, Aug 19, 2013 at 01:35:16PM -0500, Ian Pilcher wrote: - What are the advantages of having the driver built-in, as compared to simply ensuring that it's always included in the initramfs? performance, you'll take fewer tlb misses. Any links/docs to offer on this topic? http://tldp.org/HOWTO/Module-HOWTO/x627.html#MEMALLOC -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Retiring long-term FTBFS packages for Fedora 20 v2
On 08/24/2013 11:21 AM, Till Maas wrote: The following packages did not build for two releases and will be retired around 2013-08-26 unless someone rebuilds them or announces to actively working on fixing them. icecream michich Oops, I should have noticed this sooner. I would like to fix icecream. It seems you already retired it yesterday (Aug 25). Can I undo this somehow? Thanks, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mean machinery...
On 07/20/2013 06:36 AM, Doug Ledford wrote: When a shutdown task isn't proceeding as planned on Fedora 19/rawhide, am I the only one that feels like I'm staring down the monocle of a Cylon and should be preparing to die? That or it's the hood from Kit off of Knight Rider... Hi Doug, The Cylon's eye was indeed an inspiration. See the name of the function that draws it: http://cgit.freedesktop.org/systemd/systemd/commit/?id=03b717a3c4f9348807fc56e7a7d711d72d4ec0cb Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what is the F19 way to disable ipv6?
On 07/13/2013 01:44 AM, Reindl Harald wrote: please take a look at this https://bugzilla.redhat.com/show_bug.cgi?id=982740#c12 what do we do in the future to disable ipv6 entirely and why is ipv6.disable=1 as kernel param at least with 3.10.0-1.fc20.x86_64 on F19? Back in 2011 the preferred kernel parameter to do that was ipv6.disable_ipv6=1: https://lists.fedoraproject.org/pipermail/kernel/2011-June/003106.html I assume it's still true today. ipv6.disable=1 should still work though. I still see it handled net/ipv6/af_inet6.c. In the linked Bugzilla comment you mentioned ipv6disable=1 (without a dot). Did this ever work? I think it's a typo. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to remove auto generated python dependency?
On 07/09/2013 05:26 PM, Denys Vlasenko wrote: Since they have #!/usr/bin/python header, build machinery automatically adds python dependency. But I don't want this to happen - the program is very much usable without python too. Requiring python pulls in a top of other stuff which isn't needed. How can I suppress this in the specfile? This page should help: http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vote for systemd: Nay.
On 07/02/2013 04:08 PM, Jean-Marc Pigeon wrote: I was not expecting to have it fully working at the first attempt in my own container design, Would you be willing to provide some details about your container design? Ideally including the code to allow others to reproduce the problems you saw. Have you seen these recommendations?: http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ but I was expecting systemd (using systemctl very detailed status) to give me a very good insight about issues which could occur. The real goal was to learn how to use systemd components to diagnose an in trouble real system, a kind of flight simulator exercise, so that we would be ready in the future to do quick diagnosis if one of our server in a rack had trouble to boot or reboot with EL7. Interesting excersise, but I am afraid by running it in a custom container design and running under a host that itself is not using systemd you uncovered an entirely different class of problems than what can happen when running it on the host. This small exercise turned out very ugly very quickly, I worked very hard trying all the tricks and bypass I could think about to collect data. To my dismay I was unable to get a predictable behaviour, nor reliable data from systemd, even in the emergency.service mode. After a while, I was forced to face it, systemd won't help me, not even start the system in a minimal mode, I was not able to go beyond kernel level with systemd in control, services started were a total mess and container was totaly lock up, with no exploitable data provided. Not sure how much of it relates to container environments, but have you seen this?: http://freedesktop.org/wiki/Software/systemd/Debugging/ My first goal when debugging issues like this would be to make sure I can see the debugging output of systemd itself (i.e. with log_level set to debug and log_target to something I can read - probably console in the case of a container). (Quickly: we had interesting situation within the noisy and cold server room using the emergency.service console such as: $ systemctl start systemd-journald.service -- unable to comply! a dependency job for systemd-journald.service failed, see journactl -xn. This is when logging to kmsg (the dmesg buffer) or console can really help find out the problem. I ended up asking myself 'what part of this puzzle am I missing?', I digged around in Google about systemd and I was stunned by results, I found my concerns were already expressed multiple time with more talented words than mine and this as early as 2010. Since that time it is my understanding systemd continuously try to resolve problems by increasing its complexity and extending its dependencies and its centrality. this is wrong, this is very very wrong. A program as complex as systemd can't be a mandatory PID1 in an open environment as UNIX. From the above paragraphs I get the feeling you may be missing the fact that not all of systemd runs in PID1. There are more components in the systemd project, such as journald, logind, ... - they run as separate processes. There is some ambiguity when talking about systemd. Sometimes it refers only to the service manager (PID1), and sometimes to the whole suite. BTW and to go a little bit beyond the systemd case, since 1991, FC18 is the very first distribution I was NOT successful in installing on a plain hardware I heard F19 was released today with an improved Anaconda :-) Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About volatile udev directory
On 05/23/2013 11:46 AM, Sergio Belkin wrote: I've found the following in Fedora 18 [root@mpinode02 sergio]# LANG=C ls /run/udev/rules.d ls: cannot access /run/udev/rules.d: No such file or directory I haven't found anything in the changelog about a change about it, is there no more that directory ? In F17 dracut created the directory from the initramfs's init script. In F18 dracut does not use this script anymore, as the initramfs is based on systemd. I do not know if something else is supposed to create the directory. Let's ask Kay. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 05/23/2013 01:33 PM, Simone Caronni wrote: On 22 May 2013 23:18, Richard W.M. Jones wrote: (10) Get rid of multilib, /usr/lib64 etc and copy what Debian/Ubuntu are doing. might I ask the reasoning behind this? I found the current RHEL/Fedora approach much better. For example; at work we use IBM Lotus Notes, which is a 32 bit package. To install it in a 32 bit or 64 bit environment the command is the same (i.e. yum localinstall) as it will pull in the correct 32 bit dependencies. Basically hassle free. The guys that run Debian/Ubuntu notebooks, have to go through a series of dependency problems just to install the package in a 64 bit environment with getlibs and the like: http://usablesoftware.wordpress.com/2012/11/09/install-lotus-notes-8-5-3-on-ubuntu-12-10-64bit-quick-n-dirty-installation-notes/ http://www-10.lotus.com/ldd/nd85forum.nsf/DateAllThreadedWeb/69b50f2db7bb7b0b85257659005ab79e?OpenDocument These examples both suggest the use of the ia32-libs package. The package was an ugly workaround for the missing multilib support in Debian, but it should be obsolete with full multiarch in Debian 7.0. See http://wiki.debian.org/Multiarch Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 05/23/2013 01:44 PM, Jan Zelený wrote: +1 for this, the dependency hell for 32 bit applications is really a major pain in the new versions of Ubuntu. I have dealt with that multiple times and I wasn't able to resolve all the problems (e.g. Google Earth still doesn't work on Ubuntu for me) Isn't that simply because deb packages do not express library dependencies in as detailed way as rpm packages do? I'm sure Richard was not suggesting to get rid of that rpm feature. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 05/23/2013 03:10 PM, Jan Zelený wrote: On 23. 5. 2013 at 14:23:30, Michal Schmidt wrote: On 05/23/2013 01:44 PM, Jan Zelený wrote: +1 for this, the dependency hell for 32 bit applications is really a major pain in the new versions of Ubuntu. I have dealt with that multiple times and I wasn't able to resolve all the problems (e.g. Google Earth still doesn't work on Ubuntu for me) Isn't that simply because deb packages do not express library dependencies in as detailed way as rpm packages do? I'm sure Richard was not suggesting to get rid of that rpm feature. TBH I'm not perfectly sure what causes the problem but since the new multilib in Ubuntu started I am dealing with a whole bunch of issues like the one I described. So to sum up, I personally think we are doing much better with the way how things work in Fedora. In some ways we are, in other aspects we are not. Drawing conclusions from your experience with Google Earth without real understanding is a mistake. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 systemd update broke varnish service?
On 05/16/2013 11:23 PM, Michał Piotrowski wrote: I noticed that varnish service doesn't work after systemd update to version 201-2 Please file a bug. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 12:56 AM, Jeffrey Bastian wrote: The slowest component on F19 is this new wait service: 10.102s NetworkManager-wait-online.service This service doesn't seem to do anything other than wait until the network is fully up. This really skews unfavorably the boot time reported by systemd-analyze. But if I mask that service and reboot, everthing still appears to work fine and systemd-analyze reports a boot time of only 6.2 seconds. A bit OT... This is not the first time in this thread that someone mentions masking a service. Do you guys have a reason why you mask the service instead of simply disabling it? Is there anything pulling the service into your boot even when it's disabled? Thanks, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 02:25 PM, Lennart Poettering wrote: On Wed, 15.05.13 12:55, Richard W.M. Jones (rjo...@redhat.com) wrote: Is there a constructive summary anywhere of what LVM needs to do / change? This problem affects libguestfs too. It should subscribe to block devices coming and going and then assemble things as stuff appears. They have added the lvmetad daemon which does this. And it seems to be used by default on my test F19 installation. I.e. I am not seeing udev-settle being pulled in anymore. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 02:58 PM, Farkas Levente wrote: On 05/15/2013 02:48 PM, Lennart Poettering wrote: We nowadays require syslog implementations to be socket activatable, and that socket is around before normal services start, and that's guaranteed, hence nobody has to depend on syslog explicitly anymore. All services will have logging available anyway, out-of-the-box, as default, with no manual configuration necessary, and without any referring to syslog.target. is it documented? in many of your mails in this thread you wrote nowadays, anymore, default, modern system, modern hardware, etc... does it documented anywhere? what are the assumptions and how nowadays fedora should have to work? The requirements on syslog implementations to be compatible with systemd are described in: http://www.freedesktop.org/wiki/Software/systemd/syslog Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On 03/15/2013 06:53 PM, Dan Mashal wrote: On Fri, Mar 15, 2013 at 10:18 AM, Ralf Corsepius rc040...@freenet.de wrote: I am very much opposed to this change. You need to keep files which are expected to be in /bin or /sbin under these paths. /sbin is a symlink to /usr/sbin, so calling /sbin/service still works. Me too. Even with the switch to systemd I still use the service command, and plan to keep it that way. Nobody's removing the command. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On 03/15/2013 07:00 PM, Dan Mashal wrote: Looks like you guys added provides(service) and fixed the problem. Yes, Lukáš added it. He even mentioned it in the email that started this thread. Still it would be nice to drop legacy provide name after packages stop Requiring it. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On 03/15/2013 07:07 PM, Dan Mashal wrote: Well I was reading an IRC discussion on devel. I'm like a horse with blinders. This used to work and doesn't anymore. I cannot be sure, but I think you're referring here to the breakage caused by initscripts-9.45-1 due to the missing Provides: /sbin/service, but that has been added in 9.45-2. Which leads me to my next point: What does it hurt to have the command there? I was not suggesting removing the command, but merely the RPM Provides eventually. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making hplip use systemd
On 03/10/2013 10:17 PM, Luya Tshimbalanga wrote: Is it possible to allow hplip use sytemd instead of cron? We're not quite ready for a migration to timer units. Feel free to use them on your system, but before we can do it in Fedora, we need at least to: - add anacron-like mode to systemd - have a packaging policy for timer units Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 03/04/2013 04:01 PM, Matt Domsch wrote: drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; I think sfc does not really *need* to set dev_id. Yes, these are multi-port cards, but the ports are on distinct PCI functions. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive state for systemd
On 03/05/2013 04:02 AM, David Highley wrote: Unlike the bug report which indicates you can to a sync reboot, nothting but the power switch gets this system out of the issue. Did you use the -f switch? sync reboot -f Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
retiring epdfview
Hello, epdfview, a light-weight PDF viewer, is not maintained upstream anymore. The upstream developer recommends to switch to evince-gtk (a build of evince with minimal dependencies, requested in BZ#906121) or zathura. I am going to retire epdfview from Fedora. epdfview is used in Xfce and LXDE spins. The maintainers need to decide what to do. My suggestion is to use evince-gtk once/if it becomes available. Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 02/05/2013 02:53 AM, Scott Schmit wrote: Is there a program/script we can run that would tell us what the interface names would be without biosdevname (without running the new version of systemd on the box)? If you have Fedora 18 with updates applied your systemd is new enough to allow you to see the udev-generated names using: udevadm info --export -p /sys/class/net/$IFACE | grep ID_NET Example output: E: ID_NET_NAME_MAC=enx000f53014229 E: ID_NET_NAME_PATH=enp40s0f1d1 E: ID_NET_NAME_SLOT=ens4f1d1 Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On 01/24/2013 04:03 PM, Jochen Schmitt wrote: The service was not started after the configure period was expired. Was the timer unit active? What does systemctl status yourunit.timer show? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/24/2013 04:17 PM, John Reiser wrote: Another cause for concern by users is the maintenance record of systemd: https://bugzilla.redhat.com/show_bug.cgi?id=841822 pungi can't create installable media with F17 + updates For about five months from July through December 2012 The Bodhi page shows that systemd-44-20.fc17 with the fix was released in October, not December. Anyway, the bug simply did not appear that urgent to me. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Dne 10.1.2013 21:28, Kevin Fenzi napsal(a): ok, I guess I could try again. Can we remove prelink? What does it get us these days? Has anything changed about prelink since the last time it was discussed here? prelink should not mess with running executables: http://lists.fedoraproject.org/pipermail/devel/2012-July/169819.html ? Or even since prelink: is it worth it?: http://lists.fedoraproject.org/pipermail/devel/2009-July/034529.html Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can systemd/PrivateTmp bug 851970 be fixed for F17?
Dne 13.12.2012 22:52, Eric Sandeen napsal(a): I just spent too many hours re-triaging and re-discovering bug 851970, in which systemd + PrivateTmp does weird things with namespaces, thereby making it impossible to unmount filesystems under certain circumstances. 851970 was closed NEXTRELEASE, because: Not exactly. The bug was already closed before I added my comment. Michal - is there any reason why the fix mentioned in comment #5 can't be pulled back? The reason is simple. I do not understand well enough how the filesystem namespace stuff works, so I am afraid of backporting the patches that touch it. You quoted only the beginning of my comment. The unquoted part, which begins with So in order to fix this bug in F17 ..., is the starting point for anyone who is serious about wanting to help with fixing it. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
Dne 10.10.2012 14:25, David Howells napsal(a): Actually, the UsrMove has mucked up at least one way of doing things: we have/had RHEL customer(s) who kept /usr on AFS and were able to boot just using the stuff in /bin and /sbin. This is no longer a viable option with Fedora, and presumably RHEL-7. The initramfs should contain everything necessary to mount / and /usr. Isn't there a dracut module for AFS support? If not, it should be added. Has a bug been reported? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On 10/09/2012 04:45 PM, Tom Hughes wrote: On 09/10/12 15:35, Bryn M. Reeves wrote: journalctl | fgrep? This one is pretty fine by me tbh. Sure, though having just tried that is took 33s to search about a months worth of logs instead of the 0.05s that greping the last months messages took ;-) Before filing bugs about this, please test on F18 or Rawhide. The journal received performance fixes after F17. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On 10/09/2012 05:30 PM, Matthew Miller wrote: Yes. Again, you're not the first person I've heard this from. Likewise, needing to fill out the .service extension. In current versions .service is implied if no extension is provided: https://bugs.freedesktop.org/show_bug.cgi?id=39386 Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/19/2012 01:17 PM, Jakub Jelinek wrote: These days I think init reexecs itself during shutdown sequence anyway, Yes, there's a reexec or two during shutdown. After stopping the units the usual way, systemd re-execs into a helper program (/usr/lib/systemd/systemd-shutdown), which does the killing and unmounting of whatever is still left. And that's not all. Optionally it pivots back into initramfs, which can then unmount the root filesystem. so we might as well get away without restarting it. I agree. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/18/2012 12:35 AM, Sam Varshavchik wrote: Really? An example of a symbolic link pointing to a non-existent pathname? lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stderr → /proc/self/fd/2 lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stdin → /proc/self/fd/0 lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stdout → /proc/self/fd/1 You mean to tell me that none of those symlinks exist? Could've fooled me: Cut the sarcasm. In your example they existed, but generally they do not have to. Try this: $ while :; do echo hello; sleep 10; done /tmp/dumbdumbdumb [1] 32595 $ rm /tmp/dumbdumbdumb $ readlink /proc/32595/fd/1 /tmp/dumbdumbdumb (deleted) $ cat /proc/32595/fd/1 hello hello See? We have an actual magical symlink that points to a non-existing path and yet it can still be opened. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 06/21/2012 02:23 PM, Matej Cepl wrote: we don't have quality uninstall á la aptitude (remove this package and all packages which were installed just to satisfy its requirements recursively) We do now. You can set clean_requirements_on_remove=1 in yum.conf Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 06/21/2012 04:27 PM, Nikola Pajkovsky wrote: Michal Schmidt mschm...@redhat.com writes: We do now. You can set clean_requirements_on_remove=1 in yum.conf in which version that is supported? Since 3.2.28-13 http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 10:53 PM, Lennart Poettering wrote: Well, even if Mozilla fixed that, such a solution wouldn't work for OS updates, already due to privilege reasons. i.e. pre-staging changes as root which are applied when a user does something simply cannot work if you care about security or supporting multi-user systems. It's not trivial, but in theory the updates could be made to work in an RCU-like fashion: Think of running Firefox processes as RCU read-side sections. The processes that are already running before the update keep seeing the old files. Newly started processes would see the new files. The RCU grace period elapses when all the previously running processes quit. At that point the old files can be deleted. As a bonus a notification would nag the users to restart their Firefox processes. After some timeout the processes would be killed by force. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Accidentally enabled service after update from F16 to F17 - solutions?
On 06/14/2012 02:59 PM, Stanislav Ochotnicky wrote: +%triggerun -- jetty 8.1.2-9 You already have one triggerun for jetty in the spec: %triggerun -- jetty 8.1.0-3 You're likely to hit this RPM bug: https://bugzilla.redhat.com/show_bug.cgi?id=702378 +/bin/systemctl --no-reload disable jetty.service /dev/null 21 ||: +/bin/systemctl --no-reload stop jetty.service /dev/null 21 ||: This trigger will do following: If we are updating from previous releases, we disable the service and stop it if it's running I dislike this, because: - You'd just break some users' systems for the sake of a different subset of users. - Some breakage during distribution upgrade is more tolerable than breakage within regular updates. Is a running jetty really _that_ dangerous? Why do we ship it at all then? ;-) Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Accidentally enabled service after update from F16 to F17 - solutions?
On 06/14/2012 04:19 PM, Stanislav Ochotnicky wrote: Quoting Michal Schmidt (2012-06-14 15:10:56) Is a running jetty really _that_ dangerous? Why do we ship it at all then? ;-) Why do we ship Apache, tomcat and tens (hundrets?) of other useful packages? Jetty unlike most packages _is_ remotely accessible so the attack surface is rather large. If you wrote that in a jest, then sorry but I don't take my mistake that could compromise security of Fedora's users that lightly. I thought the winking smiley gave it away. But there is a basis for my jesting comment: It's great that you take security seriously, but I believe you're over-estimating the danger of the running service. Fedora has a firewall enabled by default. And I trust that the service receives any applicable security updates. The users' systems are not compromised. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On 06/06/2012 04:25 PM, Michal Schmidt wrote: We will split out a systemd-libs subpackage to be more multilib-friendly. Done in systemd-185-4.gita2368a3.fc18. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/07/2012 10:33 AM, Benny Amorsen wrote: Yes, the invokation is specified in detail. There just isn't any documentation of what it actually does, I thought what convertfs does was quite clear. If you need to know the details how it does that, take a look at /usr/lib/dracut/modules.d/30convertfs/convertfs.sh Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On 06/06/2012 03:26 PM, Adam Jackson wrote:
But if there's not going to be a systemd-libs subpackage, any issues you
do have with this scenario are systemd bugs.
We discussed it recently with Kay. We will split out a systemd-libs
subpackage to be more multilib-friendly. That said, we are not aware of
any specific issues with having both systemd.{x86_64,i686} installed.
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/06/2012 12:15 PM, Benny Amorsen wrote: 3. yum *if you follow the instructions carefully* Those instructions include dracut doing unspecified magic. For other releases I'd agree with you and do a yum upgrade, but I must admit I don't dare try this time. Upgrading with Anaconda causes the same 'magic' to be run. Despite having to do more steps manually, I had better success with upgrading to F17 using yum than with the other methods. One problem with upgrading using Anaconda from F15 was when it encountered the qt-examples package. Anaconda just reported an error in the middle of the upgrade and offered no way to continue. Recovering from that was quite painful. Further investigation showed the likely reason was a case of the known symlink vs. directory rpm issue. With yum upgrade the issue affects only the one package, but allows the transaction to finish. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On 06/06/2012 05:39 PM, Nathanael D. Noblet wrote:
Come to think of it... shouldn't the rules that come with a package be
in /lib/udev/rules.d?
Yes, but add the /usr prefix: %{_prefix}/lib/udev/rules.d/
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On 06/06/2012 05:52 PM, Garrett Holmstrom wrote: Does rpm handle binaries' colors everywhere, or just in selected locations? I'm especially curious about /usr/lib. I don't know the answer in the general case, but it definitely works for binaries in /usr/lib/systemd/. No conflicts are reported when installing systemd for both archs and all ELFs there come out as 64-bit as they should. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On 06/05/2012 03:52 AM, Kay Sievers wrote:
Systemd includes libudev.so.1, while the old libudev.rpm provided
libudev.so.0. Therefore, all packages using udev need to be rebuilt.
Here's a list of owners with packages that currently require
libudev.so.0 in Rawhide.
# repoquery --whatrequires libudev.so.0 --qf '%{sourcerpm}' | rev | cut
-f3- -d- | rev | sort | uniq | fedoradev-pkgowners | sort | column -t
ajax libdrm
bskeggsxorg-x11-drv-nouveau
davidz udisks
lennartlibatasmart
lennartlibcanberra
lennartpulseaudio
libvirt-maint libvirt
lvm-team lvm2
pgfolpc-kbdshim
rdieterqt-mobility
rhughesweston
rrelyeapcsc-lite
twaugh system-config-printer
udev-maint udev
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/01/2012 10:37 AM, Caterpillar wrote: Please apologize me, but if #820340 was not a showstopper, so which bug should be a showstopper? The bug * does not cause data loss * is easy to recover from * seems to be fixable with an update = Not what I'd call a showstopper. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On 05/24/2012 10:45 AM, drago01 wrote: On Thu, May 24, 2012 at 10:30 AM, Juan Orti Alcaine - Disable the readahead service: systemctl disable systemd-readahead-collect.service systemctl disable systemd-readahead-replay.service systemd should just do that by default (it disables it already when running on a VM). Have you measured the effects of disabling the readahead? In some past measurements readahead gave a slight benefit even with an SSD. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SystemD: When to start service for file system kernel module
On 05/23/2012 09:23 PM, Richard Shaw wrote: Here's my current service file for SPL: Lennart already pointed out a major problem, but here are some remarks about the unit file itself: [Unit] Description=Builds and installs new kmods for SPL Before=local-fs-pre.target When you are writing a unit that is meant to be run during an early phase of boot (before basic.target), you need: DefaultDependencies=no to avoid an ordering cycle. And then you can add a sensible subset of the default dependencies manually: Conflicts=shutdown.target Before=shutdown.target [Service] Type=oneshot In oneshot units it often makes sense to use: RemainAfterExit=yes It depends on whether you want to have the command re-run again or not when a subsequent request to start the unit comes (be it directly via systemctl start, or indirectly via requirement dependencies from other units). ExecStart=-/usr/sbin/akmods --from-init --akmod spl-kmod [Install] WantedBy=single-user.target There's no single-user.target. You probably meant sysinit.target. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On 05/24/2012 03:20 PM, Gerry Reno wrote: I also read here: http://ask.fedoraproject.org/question/909/enabling-trimdiscard-on-f16-using-lvm-on-luks about using TRIM with LUKS. Since I'm putting an SSD in my laptop this is important because the laptop drive must be encrypted. So is F17 going to support TRIM w/LUKS automatically? Or do we need to perform some special configuration to get TRIM w/LUKS? (Yes, I understand some attacker might be able to guess my filesystem type due to erased blocks - seems very low risk though). To use this feature, you can specify the option allow-discards in /etc/crypttab. You need systemd = 44-11, currently in updates-testing. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nginx custom script location
On 05/16/2012 12:21 AM, Jamie Nguyen wrote: /etc/init.d/nginx upgrade This has disappeared following migration to systemd, so my intention is to include an nginx-upgrade shell script to replace this functionality. My question is, where should this shell script go? In /usr/bin/nginx-upgrade? Yes, this looks like a good choice to me. Then immediately a question comes to mind: Shouldn't the script be pushed upstream, rather than being a Fedora-specific addition? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Please add GNU id-utils to Fedora
On 05/14/2012 10:11 AM, Jim Meyering wrote: Miloslav Trmač wrote: I'm pretty sure that naming conflicts in /usr/bin have happened before in Fedora, I'm not sure how they were resolved. Even in a relatively minimal system, I see many programs installed in both /sbin and /bin, though none seem to conflict: [...] Odd that some point from /bin to /sbin, and others from /sbin to /bin. Some use relative symlinks, others use absolute. These are not comparable to the lid situation. They are either: - programs using consolehelper, the legacy privilege escalation mechanism, which depends on one of the names being a symlink to consolehelper and the other name being the program itself, or - cases where the program historically lived in one directory, then was moved to the other and a symlink in the old directory was added for backwards compat. But it is the same program. They're not comparable to the lid name conflict between two different programs. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide ext4/virtio FS performance hit (10x slower) ?
On 05/13/2012 12:00 AM, Reindl Harald wrote: how can someone find out if it is a debug-kernel? even the satble ones seems to have a ton of debug options enabled especially CONFIG_DEBUG_KERNEL=y See http://fedoraproject.org/wiki/KernelDebugStrategy to find what kernel config options to look for. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Please add GNU id-utils to Fedora
On 05/11/2012 10:14 AM, Jim Meyering wrote: Technically there is no need to change a name. In Debian, one can have two lid programs installed, one in /usr/bin and the other in /usr/sbin[*], so why not in Fedora? Technically there is no problem (at least until we decide remove the distinction between sbin and bin and unify them), but it is confusing to have a command that runs completely different programs based on the $PATH order. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
updates for bugs affecting multiple releases
Reindl Harald wrote: dear maintainers: please take a tighter look for which release bugs are reported and consider that the reporter has exactly this and only this version installed and is not very happy about a has been submitted as an update for Fedora 17 notify without finding any build for the reported release on koji As long as the update for the other release does not close the BZ, I don't see anything wrong with the information about the update being posted there. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Logwatch - looking for testers
Reindl Harald wrote: i do not speak about pushig them to updates-testing or even stable i speak about give me a koji-build which i can test Making the fix apply to the stable release often requires additional backporting effort. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usrmove breaks on directory name conflict
On 04/23/2012 05:45 PM, Daniel Drake wrote: cp: cannot overwrite directory /mnt/sysimage/usr/bin.usrmove-new/mkdir with non-directory Something failed. Move back to the original state. Rebooted back into F16. It looks like the issue was that I had a directory at /usr/bin/mkdir/. No idea how, looks like it was from December. Probably my fault, but perhaps usrmove shouldn't fall over when facing this situation. If usrmove really reverted everything to its original state, it seems to me like a case of well-behaving error handling after encountering an unusual situation that cannot be resolved automatically and safely. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
Dne 3.4.2012 16:31, Chris Murphy napsal(a): My only concern about it being on tmpfs instead of on disk, is how big it could get, how much memory could be held hostage, until there's a reboot. I'd rather see it be both size and age limited (each item has a decay rate or something), so that it's evacuated more regularly than just between reboots - which could be months. Cleanup of old files is already done, by systemd-tmpfiles. See /usr/lib/tmpfiles.d/tmp.conf. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question mainline kernel on Fedora
Dne 23.3.2012 16:24, Sergio Belkin napsal(a): I've found that Fedora provides mainline kernel to download. Is mainline a release candidate? I wonder if use that version is somewhat risky... What exactly are you talking about? Could you provide the URL you found? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question mainline kernel on Fedora
Dne 23.3.2012 17:23, Sergio Belkin napsal(a): Sorry I explained it bad, I'm talking about that latest release available of kernel for f16 is kernel-3.3.0-4.fc16.x86_64 and stable is 3.2.12 That does not mean that 3.3 is somehow unstable. It is supposed to be generally usable and not dangerous. But of course there are always some bugs. That's why every $major.$minor release gets its stable branch with backported fixes. ...-- 3.2 --- 3.3-rc1 --- 3.3-rc2 --- ... --- 3.3 --- 3.4-rc1 --- ... \ \ \--- 3.2.1 --- ... --- 3.2.12 \--- 3.3.1 --- ... http://kernel.org/faq/#stablekernels Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 latest yum update hoses grub.cfg, grubby?
Dne 21.3.2012 03:56, Adam Williamson napsal: Properly, it ought to be versioned grub2-2.00-0.1.beta2.fc17. (Or possibly grub2-2.00-0.1.~beta2.fc17, I really dunno what that tilde is for). The tilde is a debianism to mark a pre-release. dpkg understands version 42~foo as lower than 42. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Slow shutdown with big file in /dev/shm
Adam Jackson wrote: Now as to why we disable swap on shutdown, I'm not really sure. It certainly seems like useless work to me. We want to be sure we'll be able to stop/disassemble any block devices that are underneath it (RAID arrays etc.). Sure, if it's a simple partition, the work is useless. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
Dne 16.3.2012 14:40, Michal Hlavinka napsal: As I understand it, Muayyad has different problem. Right now, the /etc/sysctl.conf we ship is not empty. It has several values set, one of them is sysrq=0 he used in his example. No one set this is value, it's just default value and yet, no package can change it by placing its file in /etc/sysctl.d This would work only if sysctl.conf is empty and all default configuration is moved to /etc/sysctl.d/00-systemdefault.conf See a related bug: https://bugzilla.redhat.com/show_bug.cgi?id=760254 Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making PGP distribution key well-known
Dne 1.3.2012 17:52, Petr Pisar napsal(a): where to get public key for verifying RPM signatures. The keys are at: https://fedoraproject.org/keys Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, Apple, EFI boot, livecd-tools
Dne 29.2.2012 08:36, Adam Williamson napsal(a): I think there is a parameter you can pass to entirely disable plymouth, but I forget what it is. rd.plymouth=0 plymouth.enable=0 The first is for dracut. The second disables starting of plymouth from the systemd units. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with systemd service files
On 02/26/2012 07:37 AM, Garrett Holmstrom wrote: On 2012-02-24 4:22, Juerg Haefliger wrote: So I installed the official Fedora version of cloud-init but the service startup ordering is broken there too: [root@342 ~]# dmesg | grep cloud | grep About [ 91.668396] systemd[1]: About to execute: /usr/bin/cloud-init start-local [ 91.993238] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config [ 92.540255] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final [ 92.559834] systemd[1]: About to execute: /usr/bin/cloud-init start I can't reproduce the problem. They are started in the expected order here. Juerg, is this a log of the order during boot? Or did you test the services by listing all 4 of them in systemctl start ...? The latter would show bug 704214. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with systemd service files
Dne 28.2.2012 17:23, Garrett Holmstrom napsal(a): Of interest here is the fact that the script that cloud-init-local.service runs currently has a bug that causes it to return the wrong return code. Since cloud-init.target Requires that service (cloud-config.service does not function correctly without it), two of those services should not be running at all, if I understand the systemd documentation correctly. Garrett, Juerg had an old version of systemd installed (F16 GA, no updates). After installing updates he's now getting dependency failures as you correctly anticipated :-) [ 97.114643] systemd[1]: cloud-init-local.service: main process exited, code=exited, status=1 [ 97.115478] systemd[1]: cloud-init-local.service changed start - failed [ 97.124134] systemd[1]: Job cloud-init-local.service/start finished, result=failed [ 97.124157] systemd[1]: Job cloud-config.target/start finished, result=dependency [ 97.124173] systemd[1]: Job cloud-final.service/start finished, result=dependency [ 97.124192] systemd[1]: Job cloud-final.service/start failed with result 'dependency'. [ 97.124875] systemd[1]: Job cloud-config.service/start finished, result=dependency [ 97.124894] systemd[1]: Job cloud-config.service/start failed with result 'dependency'. [ 97.125595] systemd[1]: Job cloud-config.target/start failed with result 'dependency'. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with systemd service files
On 02/24/2012 01:22 PM, Juerg Haefliger wrote: Hmm... So I fail to see the difference between After and Wants then. What's the difference between ordering and requirement dependencies? See this explanation of the orthogonality of ordering and requirement dependencies by Lennart: http://lists.fedoraproject.org/pipermail/devel/2011-April/150620.html Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
