On 05/18/2013 05:17 AM, Nicolas Mailhot wrote:
Le Sam 18 mai 2013 05:39, T.C. Hollingsworth a écrit :
On Fri, May 17, 2013 at 7:34 PM, Adam Williamson
wrote:
You could transfer the install to a system which contains a dmraid
array, or add a dmraid array to an existing install (I think this th
Adam Williamson (awill...@redhat.com) said:
> Isn't anaconda-tools the group used to ensure that things anaconda may
> need to install for particular hardware are present on images?
Live & DVD/install images, yes.
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproj
Am 17.05.2013 14:45, schrieb Lennart Poettering:
>> Here we go again:
>> https://www.dropbox.com/s/gdrdvq0kovucpsp/bootchart-20130517-1530.svg
>
> There is something really fishy... For example, from 8s to 10s the
> machine goes pretty much entirely idle... As if there was something
> doing sleep
Am 18.05.2013 11:17, schrieb Nicolas Mailhot:
>
> Le Sam 18 mai 2013 05:39, T.C. Hollingsworth a écrit :
>> On Fri, May 17, 2013 at 7:34 PM, Adam Williamson
>> wrote:
>>> You could transfer the install to a system which contains a dmraid
>>> array, or add a dmraid array to an existing install (
Le Sam 18 mai 2013 05:39, T.C. Hollingsworth a écrit :
> On Fri, May 17, 2013 at 7:34 PM, Adam Williamson
> wrote:
>> You could transfer the install to a system which contains a dmraid
>> array, or add a dmraid array to an existing install (I think this thread
>> has been considering only the cas
On Fri, May 17, 2013 at 7:34 PM, Adam Williamson wrote:
> You could transfer the install to a system which contains a dmraid
> array, or add a dmraid array to an existing install (I think this thread
> has been considering only the case of the installed system itself being
> on the RAID array). Of
On Fri, 2013-05-17 at 19:17 -0700, T.C. Hollingsworth wrote:
> On May 17, 2013 6:43 AM, "Chris Adams" wrote:
> > Once upon a time, Lennart Poettering said:
> > > I also filed this bug against anaconda, so that for the non-livecd
> > > installs we don't even get dmraid installed...
> >
> > I know
On May 17, 2013 6:43 AM, "Chris Adams" wrote:
> Once upon a time, Lennart Poettering said:
> > I also filed this bug against anaconda, so that for the non-livecd
> > installs we don't even get dmraid installed...
>
> I know there's always a goal of shrinking the base install, but I'm
> afraid we'
Le jeudi 16 mai 2013 à 14:44 -0400, john.flor...@dart.biz a écrit :
> > From: Adam Williamson
> > > How do I determine what component to file a bug against? I guess I
> > > have to find the package that caused these .service files to be
> > > installed?
> >
> > Yes. 'rpm -qf /lib/systemd/system/
On 5/17/13 5:39 PM, Chris Murphy wrote:
>
> On May 17, 2013, at 3:53 PM, Eric Sandeen wrote:
>
On Thu, 16.05.13 12:20, Chris Murphy (li...@colorremedies.com) wrote:
> There have been no crashes, so ext4 doesn't need fsck on every boot:
>
> 4.051s systemd-fsck-root
On 5/17/13 5:29 PM, Chris Murphy wrote:
>
> On May 17, 2013, at 3:56 PM, Eric Sandeen wrote:
>
>> On 5/17/13 3:58 PM, Chris Murphy wrote:
>>>
>>> Seems some extra complexity is needed anyway since the way to deal
>>> with file system problems differs with the various fs's. XFS and
>>> Btrfs fsck
On May 17, 2013, at 3:53 PM, Eric Sandeen wrote:
>>> On Thu, 16.05.13 12:20, Chris Murphy (li...@colorremedies.com) wrote:
>>>
There have been no crashes, so ext4 doesn't need fsck on every boot:
4.051s systemd-fsck-root.service
515ms
>
On May 17, 2013, at 3:56 PM, Eric Sandeen wrote:
> On 5/17/13 3:58 PM, Chris Murphy wrote:
>>
>> Seems some extra complexity is needed anyway since the way to deal
>> with file system problems differs with the various fs's. XFS and
>> Btrfs fsck's are noops. XFS needs xfs_repair run, and Btrfs
On 5/17/13 3:58 PM, Chris Murphy wrote:
>
> On May 17, 2013, at 2:38 PM, Ric Wheeler wrote:
>
>> On 05/16/2013 02:39 PM, Lennart Poettering wrote:
>>> On Thu, 16.05.13 12:20, Chris Murphy (li...@colorremedies.com) wrote:
>>>
There have been no crashes, so ext4 doesn't need fsck on every boo
On 5/17/13 3:38 PM, Ric Wheeler wrote:
> On 05/16/2013 02:39 PM, Lennart Poettering wrote:
>> On Thu, 16.05.13 12:20, Chris Murphy (li...@colorremedies.com) wrote:
>>
>>> There have been no crashes, so ext4 doesn't need fsck on every boot:
>>>
>>>4.051s systemd-fsck-root.service
>>>
On May 17, 2013, at 2:38 PM, Ric Wheeler wrote:
> On 05/16/2013 02:39 PM, Lennart Poettering wrote:
>> On Thu, 16.05.13 12:20, Chris Murphy (li...@colorremedies.com) wrote:
>>
>>> There have been no crashes, so ext4 doesn't need fsck on every boot:
>>>
>>> 4.051s systemd-fsck-root.se
On 05/15/2013 05:09 PM, Rahul Sundaram wrote:
On 05/15/2013 04:39 PM, Przemek Klosowski wrote:
I was planning to upgrade to F19 soon, and I kind-of care about the data on
that system (I have backup, but corruption would not be welcome, just for the
lost time reason). Do people recommend stickin
On 05/16/2013 02:39 PM, Lennart Poettering wrote:
On Thu, 16.05.13 12:20, Chris Murphy (li...@colorremedies.com) wrote:
There have been no crashes, so ext4 doesn't need fsck on every boot:
4.051s systemd-fsck-root.service
515ms
systemd-fsck@dev-disk-by\x2duu
On Fri, 2013-05-17 at 10:18 -0500, David Lehman wrote:
> On Fri, 2013-05-17 at 09:07 +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 05/17/2013 01:31 AM, Lennart Poettering wrote:
> > > On Thu, 16.05.13 16:17, Bill Nottingham (nott...@redhat.com) wrote:
> > >
> > >> Lennart Poettering (mzerq...@0po
On 17.05.2013 14:45, Lennart Poettering wrote:
> There is something really fishy...
…
Yeah!
The week *end* has just begun! :)
poma
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 16.05.2013 21:29, Heiko Adams wrote:
> My top 6 of extreme long starting services are:
> $ systemd-analyze blame
> 27.652s NetworkManager.service
> 27.072s chronyd.service
> 27.015s avahi-daemon.service
> 26.899s tuned.service
> 26.647s restorecond.se
On Fri, 2013-05-17 at 17:45 +0200, Lennart Poettering wrote:
> On Fri, 17.05.13 10:18, David Lehman (dleh...@redhat.com) wrote:
>
> > On Fri, 2013-05-17 at 09:07 +0200, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 05/17/2013 01:31 AM, Lennart Poettering wrote:
> > > > On Thu, 16.05.13 16:17, Bil
On Fri, 17.05.13 10:18, David Lehman (dleh...@redhat.com) wrote:
> On Fri, 2013-05-17 at 09:07 +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 05/17/2013 01:31 AM, Lennart Poettering wrote:
> > > On Thu, 16.05.13 16:17, Bill Nottingham (nott...@redhat.com) wrote:
> > >
> > >> Lennart Poettering (m
On Fri, 2013-05-17 at 09:07 +0200, Hans de Goede wrote:
> Hi,
>
> On 05/17/2013 01:31 AM, Lennart Poettering wrote:
> > On Thu, 16.05.13 16:17, Bill Nottingham (nott...@redhat.com) wrote:
> >
> >> Lennart Poettering (mzerq...@0pointer.de) said:
> RequiredBy=
> WantedBy=dmraid-activation.
On Fri, May 17, 2013 at 08:43:36 -0500,
Chris Adams wrote:
By cutting out all the hardware support except for what is in the system
at install, it becomes more difficult (like Windows) to deal with any
problems, hardware upgrades, etc. down the road.
Note that the change to defaulting to ho
On Fri, May 17, 2013 at 08:43:36AM -0500, Chris Adams wrote:
> By cutting out all the hardware support except for what is in the system
> at install, it becomes more difficult (like Windows) to deal with any
> problems, hardware upgrades, etc. down the road.
Agreed, but I think hardware-which-requ
Once upon a time, Lennart Poettering said:
> I also filed this bug against anaconda, so that for the non-livecd
> installs we don't even get dmraid installed...
I know there's always a goal of shrinking the base install, but I'm
afraid we're going overboard. One nice thing about Linux vs. Window
On Fri, 17.05.13 14:38, Heiko Adams (heiko.ad...@gmail.com) wrote:
> Am 17.05.2013 14:18, schrieb Lennart Poettering:
> > On Fri, 17.05.13 07:09, Heiko Adams (heiko.ad...@gmail.com) wrote:
> >
> >> Am 17.05.2013 01:09, schrieb Lennart Poettering:
> >>>
> >>> For the super slow run above I'd be qu
Am 17.05.2013 14:18, schrieb Lennart Poettering:
> On Fri, 17.05.13 07:09, Heiko Adams (heiko.ad...@gmail.com) wrote:
>
>> Am 17.05.2013 01:09, schrieb Lennart Poettering:
>>>
>>> For the super slow run above I'd be quite interested to have a look at
>>> the bootchart actually. (Heiko? Can you upl
On Fri, 17.05.13 09:05, Hans de Goede (hdego...@redhat.com) wrote:
> Hi,
>
> On 05/17/2013 01:21 AM, Lennart Poettering wrote:
> >On Thu, 16.05.13 13:44, Adam Williamson (awill...@redhat.com) wrote:
> >
> >>On Thu, 2013-05-16 at 20:41 +, "Jóhann B. Guðmundsson" wrote:
> >>>On 05/16/2013 08:17
On Fri, 17.05.13 07:09, Heiko Adams (heiko.ad...@gmail.com) wrote:
> Am 17.05.2013 01:09, schrieb Lennart Poettering:
> >
> > For the super slow run above I'd be quite interested to have a look at
> > the bootchart actually. (Heiko? Can you upload that?)
> >
> > Lennart
> >
> https://www.dropbo
Hi,
On 05/17/2013 01:31 AM, Lennart Poettering wrote:
On Thu, 16.05.13 16:17, Bill Nottingham (nott...@redhat.com) wrote:
Lennart Poettering (mzerq...@0pointer.de) said:
RequiredBy=
WantedBy=dmraid-activation.service
I'm not using dmraid, or md raid, or any kind of raid at the moment. I also
Hi,
On 05/17/2013 01:21 AM, Lennart Poettering wrote:
On Thu, 16.05.13 13:44, Adam Williamson (awill...@redhat.com) wrote:
On Thu, 2013-05-16 at 20:41 +, "Jóhann B. Guðmundsson" wrote:
On 05/16/2013 08:17 PM, Bill Nottingham wrote:
We *could* drop all the assorted local storage tools fr
Am 17.05.2013 01:09, schrieb Lennart Poettering:
>
> For the super slow run above I'd be quite interested to have a look at
> the bootchart actually. (Heiko? Can you upload that?)
>
> Lennart
>
https://www.dropbox.com/s/95dzgklajrgaz4n/bootchart-20130517-0756.svg
BTW: Is it correct that /dev/ma
On Fri, 2013-05-17 at 01:21 +0200, Lennart Poettering wrote:
> On Thu, 16.05.13 13:44, Adam Williamson (awill...@redhat.com) wrote:
>
> > On Thu, 2013-05-16 at 20:41 +, "Jóhann B. Guðmundsson" wrote:
> > > On 05/16/2013 08:17 PM, Bill Nottingham wrote:
> > >
> > > > We *could* drop all the as
On Thu, 16.05.13 16:17, Bill Nottingham (nott...@redhat.com) wrote:
> Lennart Poettering (mzerq...@0pointer.de) said:
> > > RequiredBy=
> > > WantedBy=dmraid-activation.service
> > >
> > > I'm not using dmraid, or md raid, or any kind of raid at the moment. I
> > > also have this entry, previou
On Thu, 16.05.13 13:44, Adam Williamson (awill...@redhat.com) wrote:
> On Thu, 2013-05-16 at 20:41 +, "Jóhann B. Guðmundsson" wrote:
> > On 05/16/2013 08:17 PM, Bill Nottingham wrote:
> >
> > > We *could* drop all the assorted local storage tools from @standard and
> > > just leave
> > > the
On Thu, 16.05.13 14:41, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Heiko Adams said:
> > My top 6 of extreme long starting services are:
> > $ systemd-analyze blame
> > 27.652s NetworkManager.service
> > 27.072s chronyd.service
> > 27.015s avahi-daemon.s
On May 16, 2013, at 1:51 PM, Chris Murphy wrote:
> But maybe wireless is causing delays just by being configured, even if a
> wired connection is available?
Not really. The one improvement is in NetworkManager-wait-online.service which
with a wired connection instead of wireless is 1/10th of
On Thu, 2013-05-16 at 20:41 +, "Jóhann B. Guðmundsson" wrote:
> On 05/16/2013 08:17 PM, Bill Nottingham wrote:
>
> > We *could* drop all the assorted local storage tools from @standard and
> > just leave
> > them to be installed by anaconda if they're being used to create such
> > storage. Th
On 05/16/2013 08:17 PM, Bill Nottingham wrote:
We*could* drop all the assorted local storage tools from @standard and just
leave
them to be installed by anaconda if they're being used to create such
storage. They'd have to remain on the live image, though, and so this would
not help installs do
On Thu, 2013-05-16 at 16:17 -0400, Bill Nottingham wrote:
> Lennart Poettering (mzerq...@0pointer.de) said:
> > > RequiredBy=
> > > WantedBy=dmraid-activation.service
> > >
> > > I'm not using dmraid, or md raid, or any kind of raid at the moment. I
> > > also have this entry, previously explain
Lennart Poettering (mzerq...@0pointer.de) said:
> > RequiredBy=
> > WantedBy=dmraid-activation.service
> >
> > I'm not using dmraid, or md raid, or any kind of raid at the moment. I also
> > have this entry, previously explained in this thread as probably not being
> > needed unless dmraid is b
On May 16, 2013, at 1:51 PM, Chris Murphy wrote:
>
> I wonder if wireless connectivity is related? When I reboot with and without
> a wired connection attached, I get the same result. But maybe wireless is
> causing delays just by being configured, even if a wired connection is
> available?
On Thu, 2013-05-16 at 11:35 -0700, Adam Williamson wrote:
> 2. Move the 'wait for abrtd' stuff to under the 'cd /sys/fs/pstore
> 2>/dev/null || exit 0' line. Then at least if /sys/fs/pstore doesn't
> exist at all, we can exit without waiting for a second.
>
> 3. Make the whole service conditional
On May 16, 2013, at 1:41 PM, Chris Adams wrote:
> Once upon a time, Heiko Adams said:
>> My top 6 of extreme long starting services are:
>> $ systemd-analyze blame
>> 27.652s NetworkManager.service
>> 27.072s chronyd.service
>> 27.015s avahi-daemon.service
>> 26.
On May 16, 2013, at 12:57 PM, Adam Williamson wrote:
> On Thu, 2013-05-16 at 12:51 -0600, Chris Murphy wrote:
>
>> And I missed one other I don't understand, which is a top 3 offender:
>>
>> 9.855s accounts-daemon.service
>> # We pull this in by graphical.target instead of waiting for
Am 16.05.2013 21:41, schrieb Chris Adams:
> Once upon a time, Heiko Adams said:
>> My top 6 of extreme long starting services are:
>> $ systemd-analyze blame
>> 27.652s NetworkManager.service
>> 27.072s chronyd.service
>> 27.015s avahi-daemon.service
>> 26.899s
Once upon a time, Heiko Adams said:
> My top 6 of extreme long starting services are:
> $ systemd-analyze blame
> 27.652s NetworkManager.service
> 27.072s chronyd.service
> 27.015s avahi-daemon.service
> 26.899s tuned.service
> 26.647s restorecond.servi
On Thu, 2013-05-16 at 21:29 +0200, Heiko Adams wrote:
> My top 6 of extreme long starting services are:
> $ systemd-analyze blame
> 27.652s NetworkManager.service
> 27.072s chronyd.service
> 27.015s avahi-daemon.service
> 26.899s tuned.service
> 26.647s
My top 6 of extreme long starting services are:
$ systemd-analyze blame
27.652s NetworkManager.service
27.072s chronyd.service
27.015s avahi-daemon.service
26.899s tuned.service
26.647s restorecond.service
23.512s lightdm.service
And I don't ha
On Thu, 16.05.13 12:15, Adam Williamson (awill...@redhat.com) wrote:
> On Thu, 2013-05-16 at 11:35 -0700, Adam Williamson wrote:
>
> > 3. Make the whole service conditional on there being anything
> > in /sys/fs/pstore at all. In practice, just doing this would resolve the
> > problems and make 1
On Thu, 2013-05-16 at 11:35 -0700, Adam Williamson wrote:
> 3. Make the whole service conditional on there being anything
> in /sys/fs/pstore at all. In practice, just doing this would resolve the
> problems and make 1 and 2 unnecessary (though still possibly desirable).
> To do that, just add thi
On Thu, 16.05.13 12:51, Chris Murphy (li...@colorremedies.com) wrote:
>
>
> On May 16, 2013, at 12:39 PM, Lennart Poettering wrote:
> >
> >
> > Hmm, on your machine, what does "systemctl show -p WantedBy -p
> > RequiredBy systemd-udev-settle.service" show? This will tell us which
> > package
On Thu, 2013-05-16 at 12:51 -0600, Chris Murphy wrote:
> And I missed one other I don't understand, which is a top 3 offender:
>
> 9.855s accounts-daemon.service
> # We pull this in by graphical.target instead of waiting for the bus
> # activation, to speed things up a little: gdm uses
On May 16, 2013, at 12:39 PM, Lennart Poettering wrote:
>
>
> Hmm, on your machine, what does "systemctl show -p WantedBy -p
> RequiredBy systemd-udev-settle.service" show? This will tell us which
> package is actually responsible for pulling in
> systemd-udev-settle.service.
RequiredBy=
Wante
On Thu, 2013-05-16 at 14:44 -0400, john.flor...@dart.biz wrote:
> > From: Adam Williamson
> > > How do I determine what component to file a bug against? I guess I
> > > have to find the package that caused these .service files to be
> > > installed?
> >
> > Yes. 'rpm -qf /lib/systemd/system/foo.
On Thu, 16.05.13 09:28, Orion Poplawski (or...@cora.nwra.com) wrote:
> On 05/16/2013 07:10 AM, Daniel J Walsh wrote:
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >On 05/14/2013 06:30 PM, Dan Williams wrote:
> >>On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote:
> >>>12.715s restor
> From: Adam Williamson
> > How do I determine what component to file a bug against? I guess I
> > have to find the package that caused these .service files to be
> > installed?
>
> Yes. 'rpm -qf /lib/systemd/system/foo.service'.
I'd actually suggest doing:
rpm -qif /lib/systemd/system/foo.serv
On Thu, 16.05.13 12:20, Chris Murphy (li...@colorremedies.com) wrote:
> There have been no crashes, so ext4 doesn't need fsck on every boot:
>
> 4.051s systemd-fsck-root.service
>515ms
>
> systemd-fsck@dev-disk-by\x2duuid-09c66d01\x2d8126\x2d39c2\x2db7b8\x2d25f14
On Thu, 2013-05-16 at 12:20 -0600, Chris Murphy wrote:
> These are the remaining items that I don't understand why they run at all, on
> every boot.
>
>
> There have been no crashes, so ext4 doesn't need fsck on every boot:
>
> 4.051s systemd-fsck-root.service
>515ms
> s
These are the remaining items that I don't understand why they run at all, on
every boot.
There have been no crashes, so ext4 doesn't need fsck on every boot:
4.051s systemd-fsck-root.service
515ms
systemd-fsck@dev-disk-by\x2duuid-09c66d01\x2d8126\x2d39c2\x2db7b8\x2d25f1
On May 16, 2013, at 7:10 AM, Daniel J Walsh wrote:
>>
>>
>>> 12.715s restorecond.service
> I have no idea why restorecond would take this much time, and it really should
> not be enabled for most machines, with file name transitions.
>
> Not sure why it is enabled. Could someone check on a fr
On 05/16/2013 07:10 AM, Daniel J Walsh wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/14/2013 06:30 PM, Dan Williams wrote:
On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote:
12.715s restorecond.service
I have no idea why restorecond would take this much time, and it really sh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/14/2013 06:30 PM, Dan Williams wrote:
> On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote:
>> This is not intended to be snarky, but I admit it could sound like it is.
>> When are long startup times for services considered to be bugs in their
On Wed, 15.05.13 15:28, Orion Poplawski (or...@cora.nwra.com) wrote:
> On 05/15/2013 03:26 PM, Bill Nottingham wrote:
> >Orion Poplawski (or...@cora.nwra.com) said:
> >>On 05/15/2013 05:36 AM, Lennart Poettering wrote:
> >>>On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote:
> >>>
On 05/15/2013 03:26 PM, Bill Nottingham wrote:
Orion Poplawski (or...@cora.nwra.com) said:
On 05/15/2013 05:36 AM, Lennart Poettering wrote:
On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote:
479ms iprupdate.service
385ms iprinit.service
These appear
Orion Poplawski (or...@cora.nwra.com) said:
> On 05/15/2013 05:36 AM, Lennart Poettering wrote:
> >On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote:
> >>479ms iprupdate.service
> >>385ms iprinit.service
> >
> >These appear to be untis that are only necess
On 05/15/2013 03:17 PM, Orion Poplawski wrote:
On 05/15/2013 05:36 AM, Lennart Poettering wrote:
On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote:
479ms iprupdate.service
385ms iprinit.service
These appear to be untis that are only necessary for IBM
On 05/15/2013 05:36 AM, Lennart Poettering wrote:
On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote:
479ms iprupdate.service
385ms iprinit.service
These appear to be untis that are only necessary for IBM RAID. It's
hugely disappointing if this is pulle
On 05/15/2013 04:39 PM, Przemek Klosowski wrote:
I was planning to upgrade to F19 soon, and I kind-of care about the
data on that system (I have backup, but corruption would not be
welcome, just for the lost time reason). Do people recommend sticking
with it? holding off the upgrade? switching
On 05/15/2013 08:39 PM, Przemek Klosowski wrote:
On 05/15/2013 02:41 PM, Dave Jones wrote:
On Wed, May 15, 2013 at 02:25:22PM +0200, Lennart Poettering wrote:
> > I Want To Believe in btrfs, but unfortunately it's still
excessively
> > buggy. It's actually got worse in Rawhide recently
On 05/15/2013 02:41 PM, Dave Jones wrote:
On Wed, May 15, 2013 at 02:25:22PM +0200, Lennart Poettering wrote:
> > I Want To Believe in btrfs, but unfortunately it's still excessively
> > buggy. It's actually got worse in Rawhide recently
>
> Well, it works fine for myself and for quite
On May 15, 2013, at 9:53 AM, Jeffrey Bastian wrote:
> On Tue, May 14, 2013 at 05:58:42PM -0600, Chris Murphy wrote:
>> And avahi doesn't play nice with the localdomain extension anyway.
>> Without the extension I ssh into boxes just like I do from Windows or
>> OS X:
>>
>> ssh chris@f19q.local
On Wed, 2013-05-15 at 14:41 -0400, Dave Jones wrote:
> On Wed, May 15, 2013 at 02:25:22PM +0200, Lennart Poettering wrote:
>
> > > I Want To Believe in btrfs, but unfortunately it's still excessively
> > > buggy. It's actually got worse in Rawhide recently
> >
> > Well, it works fine for my
On May 15, 2013, at 4:49 AM, Lennart Poettering wrote:
> On Tue, 14.05.13 17:58, Chris Murphy (li...@colorremedies.com) wrote:
>
>> Static hostname: f19q.localdomain
>> Takes 1.5 minutes before I can ssh into the VM, but the
>> sendmail.service is now about 2 seconds instead of a minute.
>
> I
On Wed, May 15, 2013 at 02:25:22PM +0200, Lennart Poettering wrote:
> > I Want To Believe in btrfs, but unfortunately it's still excessively
> > buggy. It's actually got worse in Rawhide recently
>
> Well, it works fine for myself and for quite a few other folks I know.
Cool story.
> I am
Lennart Poettering (mzerq...@0pointer.de) said:
> LVM of course has been broken like this for 5 years, and they know
> that. And they did nothing about it. And that's so disappointing...
lvmetad exists to do this now. All it requires is the patches to
plumb it in everywhere.
Bill
--
devel maili
Jeffrey Bastian (jbast...@redhat.com) said:
> On Tue, May 14, 2013 at 03:51:44PM -0600, Chris Murphy wrote:
> > But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon,
> > restorecond, all are an order of magnitude longer on F19 than F18.
>
> And it was even faster on F17. I had F17
On 05/15/2013 10:53 AM, Jeffrey Bastian wrote:
> Maybe you have iptables blocking mDNS traffic (tcp port 5353)?
UDP
--
Ian Pilcher arequip...@gmail.com
Sometimes there's nothing left
On Tue, May 14, 2013 at 05:58:42PM -0600, Chris Murphy wrote:
> And avahi doesn't play nice with the localdomain extension anyway.
> Without the extension I ssh into boxes just like I do from Windows or
> OS X:
>
> ssh chris@f19q.local
>
> Whereas if I change the hostname to f19q.localdomain, to
Once upon a time, Lennart Poettering said:
> Note that systemd puts a (configurable) limit on the number of
> concurrent connections, much like sshd does it, so there's very little
> difference... Also ssh forks of per-connection processes too, so the
> difference is probably even smaller...
The
On Wed, 15.05.13 10:05, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Matthew Miller said:
> > In that bug you suggest that administrators could change back to standalone
> > mode. Given that what you say about frequency of access is true (even on
> > systems where ssh login is a pri
On 05/15/2013 02:21 PM, Lennart Poettering wrote:
On Wed, 15.05.13 08:53, Chris Adams (li...@cmadams.net) wrote:
Once upon a time, Lennart Poettering said:
112ms iscsi.service
This really sounds like something that should be socket actviated on
demand rather than run by default.
On Wed, May 15, 2013 at 10:05:40AM -0500, Chris Adams wrote:
> Once upon a time, Matthew Miller said:
> > In that bug you suggest that administrators could change back to standalone
> > mode. Given that what you say about frequency of access is true (even on
> > systems where ssh login is a primar
Once upon a time, Matthew Miller said:
> In that bug you suggest that administrators could change back to standalone
> mode. Given that what you say about frequency of access is true (even on
> systems where ssh login is a primary activity, time between accesess is
> generally on a human scale rat
On Wed, May 15, 2013 at 04:21:20PM +0200, Lennart Poettering wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=963268
In that bug you suggest that administrators could change back to standalone
mode. Given that what you say about frequency of access is true (even on
systems where ssh login is a
On Wed, May 15, 2013 at 10:57:52AM -0400, Matthew Miller wrote:
> On Wed, May 15, 2013 at 08:53:44AM -0500, Chris Adams wrote:
> > SSH host key generation needs to be done in advance (don't want a
> > connecting socket to wait for that). Maybe that could be done with a
> > separate firstboot-like
On Wed, May 15, 2013 at 08:53:44AM -0500, Chris Adams wrote:
> SSH host key generation needs to be done in advance (don't want a
> connecting socket to wait for that). Maybe that could be done with a
> separate firstboot-like service that gets disabled once run?
Bugzilla # ? :)
--
Matthew Mille
On Wed, 2013-05-15 at 13:36 +0200, Lennart Poettering wrote:
> >236ms spice-vdagentd.service
>
> I don't see why this is on by default. According to this bug report this
> should have been pulled in on-demand only:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=876237
It probably w
On Wed, 2013-05-15 at 11:58 +0200, Paolo Bonzini wrote:
> Il 15/05/2013 05:43, Adam Williamson ha scritto:
> > On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote:
> >
> >> But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon,
> >> restorecond, all are an order of magnitude longer
On Wed, 15.05.13 15:38, Hans de Goede (hdego...@redhat.com) wrote:
> >Ah, cute, on my machine the only reason this is pulled in is
> >/etc/modules-load.d/spice-vdagentd.conf -- which also pulls in our old
> >friend uinput (see above).
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=963201
>
>
On Wed, 15.05.13 08:53, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Lennart Poettering said:
> > >112ms iscsi.service
> >
> > This really sounds like something that should be socket actviated on
> > demand rather than run by default.
>
> This is attaching to configure
On Tue, 2013-05-14 at 22:21 -0600, Chris Murphy wrote:
> I've tried both, but when I rename it I'm using 'hostnamectl set-hostname
> XXX' as I'm not seeing anything obvious in Gnome that does this.
This is on the Details panel of System Settings. You're expected to
type a "pretty" hostnames with
Once upon a time, Lennart Poettering said:
> >112ms iscsi.service
>
> This really sounds like something that should be socket actviated on
> demand rather than run by default.
This is attaching to configured iSCSI devices (which at a minimum
requires parsing configuration files to se
Hi,
On 05/15/2013 01:36 PM, Lennart Poettering wrote:
On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote:
Let me take the opportunity to dissect some of this:
236ms spice-vdagentd.service
I don't see why this is on by default. According to this bug report th
On Wed, May 15, 2013 at 01:01:18PM +0200, Lennart Poettering wrote:
> On Tue, 14.05.13 15:51, Chris Murphy (li...@colorremedies.com) wrote:
>
> > 2.911s abrt-uefioops.service
>
> I don't understand really why abrt needs to run at all by default. It
> should be spawned automatically when
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 anym
On 05/15/2013 02:48 PM, Lennart Poettering wrote:
> On Wed, 15.05.13 07:45, Dan Williams (d...@redhat.com) wrote:
>
Is anything waiting on NetworkManager-wait-online in your install? That
target is really intended for servers where you want to block Apache or
Sendmail or Database f
On Wed, 15.05.13 07:45, Dan Williams (d...@redhat.com) wrote:
> > > Is anything waiting on NetworkManager-wait-online in your install? That
> > > target is really intended for servers where you want to block Apache or
> > > Sendmail or Database from starting until you're sure your networking is
>
1 - 100 of 132 matches
Mail list logo
