regress/sys/kern/kqueue/kqueue-process (kqueue-test -P) is a test to
receive process-related events (fork/exec/exit). This test forks a
child, then forks a child-child from child. But parent checks only
child's exit. This has worked because scheduler happens to run child-child
much later.
Don't
On 2015-08-02 02:09, Benny Lofgren wrote:
> This is also a comment to Dmitris' later mail proposing an alternative
Apologies Dimitris, I managed to misspell your name.
Regards,
/Benny
On 2015-07-25 21:20, Martin Pieuchot wrote:
> On 13/07/15(Mon) 14:04, Dimitris Papastamos wrote:
>> Hi,
>>
>> I noticed -f in ndp(8) did nothing at all so I've enabled it and
>> documented the file syntax in the man page.
>
> If it does nothing, I'd say let's kill it.
Looking at the code, that lo
On Sat, 01 Aug 2015 12:12:01 -0700, Philip Guenther wrote:
> Since my error was moving code across a goto, I'm inclined to kill the
> goto completely, like this:
That is easier to follow to boot. OK millert@
- todd
On Sat, Aug 1, 2015 at 12:05 PM, Doug Hogan wrote:
> On Sat, Aug 01, 2015 at 07:31:58PM +0100, Mark Latimer wrote:
>> reading through the compiler warnings I believe there is a potential issue
>> in /usr/src/sys/kern/kern_ktrace.c At first glance it appears to free
>> an uninitialized pointer memp
On Sat, Aug 01, 2015 at 07:31:58PM +0100, Mark Latimer wrote:
> reading through the compiler warnings I believe there is a potential issue
> in /usr/src/sys/kern/kern_ktrace.c At first glance it appears to free
> an uninitialized pointer memp.
I agree.
Index: sys/kern/kern_ktrace.c
=
Hello,
reading through the compiler warnings I believe there is a potential issue
in /usr/src/sys/kern/kern_ktrace.c At first glance it appears to free
an uninitialized pointer memp.
Regards
int
ktruser(struct proc *p, const char *id, const void *addr, size_t len)
{
struct ktr_header kth
The root cause for a recent problem reported on misc@ [0] was
determined to be setting kern.securelevel=2 in sysctl.conf. [1]
To perhaps prevent the provisioning error from happening to others,
I propose the following clarification to securelevel(7). I percieve the
setting as little more than a
On Sat, Aug 01, 2015 at 11:23:56AM +0200, Theo Buehler wrote:
> If the `rcctl ls' command is given an argument that requires root,
> the error message has a awkward space in front of the colon since
> no argument is passed to the needs_root() function:
>
> $ rcctl ls started
> rcctl : need root pr
If the `rcctl ls' command is given an argument that requires root,
the error message has a awkward space in front of the colon since
no argument is passed to the needs_root() function:
$ rcctl ls started
rcctl : need root privileges
Since this is the only place where `needs_root()' is called with
On Sat, Aug 01, 2015 at 08:25:06AM +0100, Jason McIntyre wrote:
>
> if we do it this way, it almost sounds like we're recommending people do
> this. if the default is now root logins are denied, i'd say telling
> people how to permit them has no relevant place in afterboot(8). so i
> propose zappi
On Sat, Aug 01, 2015 at 08:25:06AM +0100, Jason McIntyre wrote:
> On Fri, Jul 31, 2015 at 07:20:36PM -0400, Michael Reed wrote:
> > Hi all,
> >
> > I noticed that the default for the sshd_config option "PermitRootLogin"
> > changed from "yes" to "no" [1], but afterboot(8) still refers to it as
> >
On Fri, Jul 31, 2015 at 07:20:36PM -0400, Michael Reed wrote:
> Hi all,
>
> I noticed that the default for the sshd_config option "PermitRootLogin"
> changed from "yes" to "no" [1], but afterboot(8) still refers to it as
> if "yes" is the default.
>
> Perhaps the sub-section could be reworded a b
13 matches
Mail list logo
