starlight | 8 Feb 02:13
Favicon

Re: suggestion for improvement to vfork() man page

At 12:04 PM 2/8/2012 +1300, Michael Kerrisk wrote:
>Hi,
>
>On Wed, Feb 8, 2012 at 10:50 AM,  <starlight@...> wrote:
>> +(However, on such systems,
>> +the preferred standard way of accomplishing the same result is to use
>> +.BR posix_spawn (3).)
>>
>> I'm not sure I agree on this.  Linux posix_spawn()
>> calls fork()
>
>I think isn't quite correct. I believe glibc's posix_spawn uses
>vfork() where it can. See sysdeps/posix/spawni.c::spawni().

Looked at glibc-2.9 and posix_spawn() uses
fork() in only when no process attibutes are
modified (i.e. it respects the AIX and Solaris
semantics of vfork though this is a bit irrelevent
since AIX and Solaris have kernel-native support
for posix_spawn) or when a non-standard
POSIX_SPAWN_USEVFORK flag is present.  It's
rather muddy so I stick with #ifdef vfork()
for Linux and #ifdef posix_spawn() for the
*nixes.

>
>So, I'll change that last sentence to
>
>[[
>(POSIX.1-2008 removed vfork() from the standard; the POSIX rationale
(Continue reading)

starlight | 7 Feb 22:34
Favicon

Re: suggestion for improvement to vfork() man page

Looks good.  Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michael Kerrisk | 7 Feb 18:24
Picon
Gravatar

Re: documentation typo

On Mon, Feb 6, 2012 at 2:19 PM, Christopher Patton
<chpatton013@...> wrote:
> man close
> second paragraph under DESPRIPTION:
> "[...] are freed; if  the descriptor was [...]"
> two spaces between if and the

Christopher,

This is just the output of groff--it happens to add the space padding
there to right justify the text. Or have I missed your point?

Thanks,

Michael

--

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Elie De Brauwer | 7 Feb 08:48
Picon
Gravatar

proc(5) and definition of loadavg

Hello all,

I've got a small suggestion related to man 5 proc (
http://www.kernel.org/doc/man-pages/online/pages/man5/proc.5.html ).
If you go to /proc/loadavg it states

<quote>
 The fourth field consists of two numbers separated by a slash (/).
The first of these is the number of currently executing kernel
scheduling entities (processes, threads); this will be less than or
equal to the number of CPUs.  The value after the slash is the number
of kernel scheduling entities that currently exist on the system.
</quote>

When I take a look at /proc/loadavg this seems to make sense:

edb <at> lapedb:~$ cat /proc/loadavg
0.04 0.65 0.59 1/284 8102

However, suppose I run 4 background jobs of 'yes bla > /dev/null &'

edb <at> lapedb:~$ yes bla > /dev/null &
[1] 8111
edb <at> lapedb:~$ yes bla > /dev/null &
[2] 8112
edb <at> lapedb:~$ yes bla > /dev/null &
[3] 8113
edb <at> lapedb:~$ yes bla > /dev/null &
[4] 8114
edb <at> lapedb:~$ cat /proc/loadavg
(Continue reading)

bugzilla | 3 Feb 09:13

[Bug 13608] Invalid default in bridge-nf-filter-vlan-tagged description

https://bugzilla.kernel.org/show_bug.cgi?id=13608

Michael Kerrisk <mtk.manpages@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |mtk.manpages@...
         Resolution|                            |WILL_NOT_FIX

--- Comment #2 from Michael Kerrisk <mtk.manpages@...> 
2012-02-03 08:13:30 ---
Closing, as this doesn't appear to be a bug in a man page. If I've missed
something, please reopen, or reopen and assign to the appropriate maintainer.

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michael Kerrisk | 2 Feb 20:04
Picon
Gravatar

Re: Typo in scanf

On Fri, Nov 18, 2011 at 8:31 PM, Alain <alainb06@...> wrote:
> There is a typo in the example given under "Note" section.
>
> Sorry I saw just now that there is a very easy way to report that by mail...
> I already files the report (and details such as version used = Ubuntu
> 10.04.3) here :
>
> https://bugs.launchpad.net/ubuntu/+source/man-db/+bug/891854
>
> Typo is:
>
> fprintf(stderr, "No matching characters\n"):
>
> Should be instead
>
> fprintf(stderr, "No matching characters\n");
>
>
> ( ';' semicolon terminates an C instruction, and not ':' colon )
>
> I also made a suggestion (see bug report), to change the example using the
> 'm' modifier as 'a' seems rather dangerous and obsolete.
> This second part is just a suggestion (subject to discussion) whereas the
> typo is really there and makes compiling without errors impossible.
>
> Best regards.
> Alain BENEDETTI

Thanks Alain. Fixed!

(Continue reading)

Michael Kerrisk | 2 Feb 19:59
Picon
Gravatar

Re: A typo in the wcslen man page.

On Mon, Dec 19, 2011 at 2:24 AM, carado <carado@...> wrote:
> Hello.
>
> I believe I have found a typo in the man page of wcslen (section 3).
> It says “the terminating null wide chharacter” with “chharacter” instead of
> “character”.
>
> Thank you for taking the time to read this,

Thanks! Fixed.

Cheers,

Michael

--

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bugzilla | 31 Jan 19:17

[Bug 42705] New: ioctl prototype is incorrect

https://bugzilla.kernel.org/show_bug.cgi?id=42705

           Summary: ioctl prototype is incorrect
           Product: Documentation
           Version: unspecified
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: man-pages
        AssignedTo: documentation_man-pages@...
        ReportedBy: kosaki.motohiro@...
        Regression: No

Now, the ioctl man page (*) says ioctl declaration is

    int ioctl(int d, int request, ...);

(*) http://www.kernel.org/doc/man-pages/online/pages/man2/ioctl.2.html

But, actual glibc implementtion has a different type.

/usr/include/sys/ioctl.h:
  extern int ioctl (int __fd, unsigned long int __request, ...) __THROW;

Look, __request parameter actually has unsigned long type. it's not int.
It would be better if the man respect an implemtation.

(Continue reading)

bugzilla | 31 Jan 19:00

[Bug 42704] New: execve may return EAGAIN on v3.1 or later

https://bugzilla.kernel.org/show_bug.cgi?id=42704

           Summary: execve may return EAGAIN on v3.1 or later
           Product: Documentation
           Version: unspecified
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: man-pages
        AssignedTo: documentation_man-pages@...
        ReportedBy: kosaki.motohiro@...
        Regression: No

Following commit changed RLIMIT_NPROC rule. now set*uid() never return EAGAIN.
And instead,
execve() may return EAGAIN.

If man pages respect this change, it would be better.

commit 72fa59970f8698023045ab0713d66f3f4f96945c
Author: Vasiliy Kulikov 
Date:   Mon Aug 8 19:02:04 2011 +0400

    move RLIMIT_NPROC check from set_user() to do_execve_common()

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
(Continue reading)

Jon Grant | 21 Jan 22:48

aio_error query

Hello

http://www.kernel.org/doc/man-pages/online/pages/man3/aio_error.3.html

Is this really positive? errno is an int, and the values I think are not 
guaranteed to be positive (like with glibc). I work on a system where 
they are all negative.

        *  A positive error, if the asynchronous I/O operation failed. 
This is the
           same value that would have been stored in the errno variable 
in the case of
           a synchronous read(2), write(2), fsync(2), or fdatasync(2) call.

Best regards, Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jon Grant | 21 Jan 22:44

aio_return man page different from aio_read

Hello

aio_read also describes aio_return will return -1 on error:

http://www.kernel.org/doc/man-pages/online/pages/man3/aio_read.3.html

However, aio_return man page does not explain this, it says the error 
code returned directly:

"If the asynchronous I/O operation has completed, this function returns the
        value that would have been returned in case of a synchronous 
read(2),
        write(2), fsync(2) or fdatasync(2), call."

http://www.kernel.org/doc/man-pages/online/pages/man3/aio_return.3.html

I don't know which is correct.

Best regards, Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane