Maxim Sobolev wrote
in :
so> I've committed another fix for the syslogd code in question which should
so> hopefully make it functional again. Peter, please let me know if you still
so> having any issues.
Am Sat, 15 Apr 2017 14:22:57 -0500
Larry Rosenman schrieb:
> This looks MUCH better, startup was it’s usual speedy self.
>
>
>
>
>
... same here with FreeBSD 12.0-CURRENT #23 r316999: Sun Apr 16 07:28:14 CEST
2017 amd64.
Systems boot as usual again - speedy and
t;, <svn-src-all@freebsd.org>, Hiroki
Sato <h...@freebsd.org>, Hiren Panchasara <hi...@freebsd.org>,
<svn-src-h...@freebsd.org>, Ngie Cooper <yaneurab...@gmail.com>
Subject: Re: svn commit: r316874 - head/sys/kern
I've committed another fix for the syslogd code
I've committed another fix for the syslogd code in question which should
hopefully make it functional again. Peter, please let me know if you still
having any issues. Thanks!
-Max
On Sat, Apr 15, 2017 at 8:46 AM, O. Hartmann wrote:
> Am Sat, 15 Apr 2017 08:05:23 -0500
>
Am Sat, 15 Apr 2017 08:05:23 -0500
Larry Rosenman schrieb:
> On 4/15/17, 6:00 AM, "Maxim Sobolev" of
> sobo...@freebsd.org> wrote:
>
> Peter, Ngie, none of this stuff is really directly related to the
> shutdown(2) change, so
On 4/15/17, 6:00 AM, "Maxim Sobolev" wrote:
Peter, Ngie, none of this stuff is really directly related to the
shutdown(2) change, so I'll probably let Hiroki to clean it up.
-Max
I’ve backed off to my previous
Peter, Ngie, none of this stuff is really directly related to the
shutdown(2) change, so I'll probably let Hiroki to clean it up.
-Max
On Fri, Apr 14, 2017 at 11:58 PM, Peter Wemm wrote:
> On Friday, April 14, 2017 08:13:52 PM Ngie Cooper wrote:
> > > On Apr 14, 2017, at 20:12,
On Friday, April 14, 2017 08:13:52 PM Ngie Cooper wrote:
> > On Apr 14, 2017, at 20:12, Peter Wemm wrote:
> >
> > On Friday, April 14, 2017 07:36:55 PM Peter Wemm wrote:
> >> On Friday, April 14, 2017 02:14:16 PM Ngie Cooper wrote:
> On Apr 14, 2017, at 14:10, Maxim Sobolev
> On Apr 14, 2017, at 20:12, Peter Wemm wrote:
>
> On Friday, April 14, 2017 07:36:55 PM Peter Wemm wrote:
>> On Friday, April 14, 2017 02:14:16 PM Ngie Cooper wrote:
On Apr 14, 2017, at 14:10, Maxim Sobolev wrote:
Peter, Ngie,
On Friday, April 14, 2017 07:36:55 PM Peter Wemm wrote:
> On Friday, April 14, 2017 02:14:16 PM Ngie Cooper wrote:
> > > On Apr 14, 2017, at 14:10, Maxim Sobolev wrote:
> > >
> > > Peter, Ngie,
> > >
> > > Looks like out of that refactoring came a logical bug that is
On Friday, April 14, 2017 02:14:16 PM Ngie Cooper wrote:
> > On Apr 14, 2017, at 14:10, Maxim Sobolev wrote:
> >
> > Peter, Ngie,
> >
> > Looks like out of that refactoring came a logical bug that is present in
> > the head, which causes syslod to first to shutdown the
On Friday, April 14, 2017 02:21:05 PM Maxim Sobolev wrote:
> Peter, It is actually the other way around. If you take syslogd code out of
> 11-stable and earlier that would work just fine with or without r316874.
> But since r285910 syslogd in head had been refactored a lot and I think
> that
On Friday, April 14, 2017 02:10:56 PM Maxim Sobolev wrote:
> Peter, Ngie,
>
> Looks like out of that refactoring came a logical bug that is present in
> the head, which causes syslod to first to shutdown the socket for reading
> and then try to select/recv on it (which is somewhat stupid). And
On Friday, April 14, 2017 02:21:05 PM Maxim Sobolev wrote:
> Peter, It is actually the other way around. If you take syslogd code out of
> 11-stable and earlier that would work just fine with or without r316874.
> But since r285910 syslogd in head had been refactored a lot and I think
> that
Peter, It is actually the other way around. If you take syslogd code out of
11-stable and earlier that would work just fine with or without r316874.
But since r285910 syslogd in head had been refactored a lot and I think
that particular bug has introduced that has been masked by the shutdown()
on
> On Apr 14, 2017, at 14:10, Maxim Sobolev wrote:
>
> Peter, Ngie,
>
> Looks like out of that refactoring came a logical bug that is present in the
> head, which causes syslod to first to shutdown the socket for reading and
> then try to select/recv on it (which is
Peter, Ngie,
Looks like out of that refactoring came a logical bug that is present in
the head, which causes syslod to first to shutdown the socket for reading
and then try to select/recv on it (which is somewhat stupid). And that
issue has been masked by shutdown() on datagram socket becoming
> On Apr 14, 2017, at 12:46, Peter Wemm wrote:
>
> On Friday, April 14, 2017 12:41:52 PM Maxim Sobolev wrote:
>> Thanks, Peter. I will try to look into this asap.
>
> I don't understand what is going on yet. Presumably there must be other
> changes in play that affect
On Friday, April 14, 2017 12:41:52 PM Maxim Sobolev wrote:
> Thanks, Peter. I will try to look into this asap.
I don't understand what is going on yet. Presumably there must be other
changes in play that affect udp/select sometime between the original 2015
change and this. The syslogd -s code
Thanks, Peter. I will try to look into this asap.
-Max
On Apr 14, 2017 12:32 PM, "Peter Wemm" wrote:
> On Friday, April 14, 2017 11:49:26 AM Peter Wemm wrote:
> > On Friday, April 14, 2017 05:23:28 PM Maxim Sobolev wrote:
> > > Author: sobomax
> > > Date: Fri Apr 14 17:23:28
On Friday, April 14, 2017 11:49:26 AM Peter Wemm wrote:
> On Friday, April 14, 2017 05:23:28 PM Maxim Sobolev wrote:
> > Author: sobomax
> > Date: Fri Apr 14 17:23:28 2017
> > New Revision: 316874
> > URL: https://svnweb.freebsd.org/changeset/base/316874
> >
> > Log:
> > Restore ability to
On Friday, April 14, 2017 05:23:28 PM Maxim Sobolev wrote:
> Author: sobomax
> Date: Fri Apr 14 17:23:28 2017
> New Revision: 316874
> URL: https://svnweb.freebsd.org/changeset/base/316874
>
> Log:
> Restore ability to shutdown DGRAM sockets, still forcing ENOTCONN to be
> returned by the
Author: sobomax
Date: Fri Apr 14 17:23:28 2017
New Revision: 316874
URL: https://svnweb.freebsd.org/changeset/base/316874
Log:
Restore ability to shutdown DGRAM sockets, still forcing ENOTCONN to be
returned
by the shutdown(2) system call. This ability has been lost as part of the svn
23 matches
Mail list logo