* Re: Bug#1094283: util-linux: dmesg shows color when /etc/terminal-colors.d/disable is present (and no override in xdg locations)
From: Thomas Weißschuh @ 2025-02-03 20:53 UTC (permalink / raw)
To: Chris Hofstaedtler; +Cc: util-linux, Axel, 1094283
In-Reply-To: <Z5a08yD10L1J8AIa@per.namespace.at>
Hi Chris,
On 2025-01-26 23:19:31+0100, Chris Hofstaedtler wrote:
> it appears commit 4bdf22803f9a41329694e0c3c82189635dccdcd0 breaks
> disabling colors using the documented mechanism of touching
> /etc/terminal-colors.d/dmesg.disable. See below for a user report.
Thanks for the report.
> On Sun, Jan 26, 2025 at 07:19:09PM +0100, Axel wrote:
> > Package: util-linux
> > Version: 2.40.4-1
> >
> > Running dmesg after upgrading to trixie started showing color. The manpage
> > mentions creating /etc/terminal-colors.d/disable which should disable colors
> > for all. Creating the also mentioned /etc/terminal-colors.d/dmesg.disable
> > doesn't disable color output also. I had /etc/terminal-colors.d/disable
> > configured which did disable colors on -stable.
>
> From what I can tell, the new rc = -ENOENT in colors_readdir
> introduced in 4bdf22803f9a41329694e0c3c82189635dccdcd0 bubbles up to
> colors_init:
>
> int rc = colors_read_configuration(cc); // calls colors_readdir, now returns -2
> if (rc)
> cc->mode = UL_COLORMODE_DEFAULT;
> else {
> Evaluating color scores is skipped, effectively ignoring the
> "disable" file.
>
> Could you please take a look?
Could you test https://github.com/util-linux/util-linux/pull/3397 ?
Thomas
^ permalink raw reply
* Re: [PATCH v2] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support
From: John Paul Adrian Glaubitz @ 2025-02-03 11:55 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Maciej W. Rozycki, Arnd Bergmann, Richard Henderson, Matt Turner,
Kees Cook, Paul E. McKenney, linux-alpha, linux-mm, linux-kernel,
Michael Cree, Sam James, Geert Uytterhoeven, Michael Karcher,
Chris Hofstaedtler, util-linux, linux-mips, loongarch
In-Reply-To: <87y0zfs26i.fsf_-_@email.froward.int.ebiederm.org>
Hi,
On Sun, 2025-01-12 at 23:39 -0600, Eric W. Biederman wrote:
> Richard Henderson <richard.henderson@linaro.org> writes[1]:
>
> > There was a Spec benchmark (I forget which) which was memory bound and ran
> > twice as fast with 32-bit pointers.
> >
> > I copied the idea from DEC to the ELF abi, but never did all the other work
> > to allow the toolchain to take advantage.
> >
> > Amusingly, a later Spec changed the benchmark data sets to not fit into a
> > 32-bit address space, specifically because of this.
> >
> > I expect one could delete the ELF bit and personality and no one would
> > notice. Not even the 10 remaining Alpha users.
>
> In [2] it was pointed out that parts of setarch weren't working
> properly on alpha because it has it's own SET_PERSONALITY
> implementation. In the discussion that followed Richard Henderson
> pointed out that the 32bit pointer support for alpha was never
> completed.
>
> Fix this by removing alpha's 32bit pointer support.
>
> As a bit of paranoia refuse to execute any alpha binaries that have
> the EF_ALPHA_32BIT flag set. Just in case someone somewhere has
> binaries that try to use alpha's 32bit pointer support.
>
> [1] https://lkml.kernel.org/r/CAFXwXrkgu=4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq4ttm52pJOQ@mail.gmail.com
> [2] https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-berlin.de
> v1: https://lkml.kernel.org/r/87jzb2tdb7.fsf_-_@email.froward.int.ebiederm.org
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
>
> Kees can you pick this one up?
>
> arch/alpha/include/asm/elf.h | 6 +-----
> arch/alpha/include/asm/pgtable.h | 2 +-
> arch/alpha/include/asm/processor.h | 8 ++------
> arch/alpha/kernel/osf_sys.c | 11 ++---------
> 4 files changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h
> index 4d7c46f50382..50c82187e60e 100644
> --- a/arch/alpha/include/asm/elf.h
> +++ b/arch/alpha/include/asm/elf.h
> @@ -74,7 +74,7 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
> /*
> * This is used to ensure we don't load something for the wrong architecture.
> */
> -#define elf_check_arch(x) ((x)->e_machine == EM_ALPHA)
> +#define elf_check_arch(x) (((x)->e_machine == EM_ALPHA) && !((x)->e_flags & EF_ALPHA_32BIT))
>
> /*
> * These are used to set parameters in the core dumps.
> @@ -137,10 +137,6 @@ extern int dump_elf_task(elf_greg_t *dest, struct task_struct *task);
> : amask (AMASK_CIX) ? "ev6" : "ev67"); \
> })
>
> -#define SET_PERSONALITY(EX) \
> - set_personality(((EX).e_flags & EF_ALPHA_32BIT) \
> - ? PER_LINUX_32BIT : PER_LINUX)
> -
> extern int alpha_l1i_cacheshape;
> extern int alpha_l1d_cacheshape;
> extern int alpha_l2_cacheshape;
> diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
> index 635f0a5f5bbd..02e8817a8921 100644
> --- a/arch/alpha/include/asm/pgtable.h
> +++ b/arch/alpha/include/asm/pgtable.h
> @@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
>
> extern void paging_init(void);
>
> -/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT. */
> +/* We have our own get_unmapped_area */
> #define HAVE_ARCH_UNMAPPED_AREA
>
> #endif /* _ALPHA_PGTABLE_H */
> diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h
> index 55bb1c09fd39..5dce5518a211 100644
> --- a/arch/alpha/include/asm/processor.h
> +++ b/arch/alpha/include/asm/processor.h
> @@ -8,23 +8,19 @@
> #ifndef __ASM_ALPHA_PROCESSOR_H
> #define __ASM_ALPHA_PROCESSOR_H
>
> -#include <linux/personality.h> /* for ADDR_LIMIT_32BIT */
> -
> /*
> * We have a 42-bit user address space: 4TB user VM...
> */
> #define TASK_SIZE (0x40000000000UL)
>
> -#define STACK_TOP \
> - (current->personality & ADDR_LIMIT_32BIT ? 0x80000000 : 0x00120000000UL)
> +#define STACK_TOP (0x00120000000UL)
>
> #define STACK_TOP_MAX 0x00120000000UL
>
> /* This decides where the kernel will search for a free chunk of vm
> * space during mmap's.
> */
> -#define TASK_UNMAPPED_BASE \
> - ((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / 2)
> +#define TASK_UNMAPPED_BASE (TASK_SIZE / 2)
>
> /* This is dead. Everything has been moved to thread_info. */
> struct thread_struct { };
> diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
> index 86185021f75a..a08e8edef1a4 100644
> --- a/arch/alpha/kernel/osf_sys.c
> +++ b/arch/alpha/kernel/osf_sys.c
> @@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
> return ret;
> }
>
> -/* Get an address range which is currently unmapped. Similar to the
> - generic version except that we know how to honor ADDR_LIMIT_32BIT. */
> +/* Get an address range which is currently unmapped. */
>
> static unsigned long
> arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
> @@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
> unsigned long len, unsigned long pgoff,
> unsigned long flags, vm_flags_t vm_flags)
> {
> - unsigned long limit;
> -
> - /* "32 bit" actually means 31 bit, since pointers sign extend. */
> - if (current->personality & ADDR_LIMIT_32BIT)
> - limit = 0x80000000;
> - else
> - limit = TASK_SIZE;
> + unsigned long limit = TASK_SIZE;
>
> if (len > limit)
> return -ENOMEM;
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Can someone pick up this patch for v6.14?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* [PATCH 2/2] setpriv: describe --groups more correctly in the usage text
From: Benno Schulenberg @ 2025-02-02 16:38 UTC (permalink / raw)
To: util-linux
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
sys-utils/setpriv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sys-utils/setpriv.c b/sys-utils/setpriv.c
index f68e6c48a..43d72f64c 100644
--- a/sys-utils/setpriv.c
+++ b/sys-utils/setpriv.c
@@ -146,7 +146,7 @@ static void __attribute__((__noreturn__)) usage(void)
fputs(_(" --clear-groups clear supplementary groups\n"), out);
fputs(_(" --keep-groups keep supplementary groups\n"), out);
fputs(_(" --init-groups initialize supplementary groups\n"), out);
- fputs(_(" --groups <group,...> set supplementary groups by UID or name\n"), out);
+ fputs(_(" --groups <group>[,...] set supplementary group(s) by GID or name\n"), out);
fputs(_(" --securebits <bits> set securebits\n"), out);
fputs(_(" --pdeathsig keep|clear|<signame>\n"
" set or clear parent death signal\n"), out);
--
2.48.1
^ permalink raw reply related
* [PATCH] setpriv: consistently use "<caps>" to indicate a list of capabilities
From: Benno Schulenberg @ 2025-02-02 16:06 UTC (permalink / raw)
To: util-linux
The existing "<caps,...>" did not indicate that each capability name
must be preceded by "+" or "-". Also, to indicate that the list needs
to be separated by commas, one would have to use "<cap>[,...]", not
"<cap,...>". So... instead of trying to cram all that info in there,
just say "<caps>", like for --bounding-set.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
sys-utils/setpriv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sys-utils/setpriv.c b/sys-utils/setpriv.c
index 907845545..f68e6c48a 100644
--- a/sys-utils/setpriv.c
+++ b/sys-utils/setpriv.c
@@ -134,8 +134,8 @@ static void __attribute__((__noreturn__)) usage(void)
fputs(USAGE_OPTIONS, out);
fputs(_(" -d, --dump show current state (and do not exec)\n"), out);
fputs(_(" --nnp, --no-new-privs disallow granting new privileges\n"), out);
- fputs(_(" --ambient-caps <caps,...> set ambient capabilities\n"), out);
- fputs(_(" --inh-caps <caps,...> set inheritable capabilities\n"), out);
+ fputs(_(" --ambient-caps <caps> set ambient capabilities\n"), out);
+ fputs(_(" --inh-caps <caps> set inheritable capabilities\n"), out);
fputs(_(" --bounding-set <caps> set capability bounding set\n"), out);
fputs(_(" --ruid <uid|user> set real uid\n"), out);
fputs(_(" --euid <uid|user> set effective uid\n"), out);
--
2.48.1
^ permalink raw reply related
* [PATCH] lscpu: skip frequencies of 0 MHz when getting minmhz
From: Ricardo Neri @ 2025-01-31 3:25 UTC (permalink / raw)
To: util-linux; +Cc: Ricardo Neri, Ricardo Neri
read_mhz() sets cpu->mhz_min_freq from /sys/devices/system/cpu/cpuN/
cpufreq/cpuinfo_min_freq. The file read fails if cpuN is offline and
cpu->mhz_min_freq is left as 0. 0 MHz is treated as invalid frequency.
lsblk_cputype_get_minmhz() iterates through all possible CPUs to find the
minimum frequency. If one or more CPUs are offline, the minimum frequency
will be 0. This is reflected in the output of lscpu:
$ ./lscpu | grep min
CPU min MHz: 0.0000
Ignore 0-MHz frequencies to find the actual minimum frequency:
$ ./lscpu | grep min
CPU min MHz: 1200.0000
Reported-by: Thangamani Krishnan <thangamani.krishnan@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
sys-utils/lscpu-topology.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sys-utils/lscpu-topology.c b/sys-utils/lscpu-topology.c
index 547a3aca0..36a217bc7 100644
--- a/sys-utils/lscpu-topology.c
+++ b/sys-utils/lscpu-topology.c
@@ -660,6 +660,8 @@ float lsblk_cputype_get_minmhz(struct lscpu_cxt *cxt, struct lscpu_cputype *ct)
if (!cpu || cpu->type != ct || !is_cpu_present(cxt, cpu))
continue;
+ if (!cpu->mhz_min_freq)
+ continue;
if (res < 0.0 || cpu->mhz_min_freq < res)
res = cpu->mhz_min_freq;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] Add setsid option to save child process id
From: Marc Aurèle La France @ 2025-01-30 18:05 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
In-Reply-To: <alpine.WNT.2.20.2501290953590.4996@CLUIJ>
On Wed, 2025-Jan-29, Marc Aurèle La France wrote:
> On Wed, 2025-Jan-29, Karel Zak wrote:
>> On Sun, Jan 26, 2025 at 10:40:19AM GMT, Marc Aurèle La France wrote:
It would appear some clarification is in order here.
>>> Add an option to save the child's pid into a file.
>>> @@ -105,6 +115,16 @@ int main(int argc, char **argv)
>>> break;
>>> default:
>>> /* parent */
>>> + if (pidpath) {
>>> + pidfile = fopen(pidpath, "w");
>>> + if (pidfile == NULL)
>>> + warn(_("cannot open pidfile %s"),
>>> + pidpath);
>>> + else {
>>> + fprintf(pidfile, "%d\n", pid);
>>> + fclose(pidfile);
>>> + }
>>> + }
>>> if (!status)
>>> return EXIT_SUCCESS;
>>> if (wait(&status) != pid)
>> What is the intended use-case for this feature?
> To put various utilities (ping, tcpdump, ad nauseam) in the background and
> have a simple way of controlling each instance individually.
>> I am unsure if this implementation is too simplistic.
Yes, that's what the KISS principle is about.
>> It seems that the file is not deleted after the child process exits.
This could be done, but only if --wait is also specified.
>> Furthermore, what would happen if we call multiple setsid instances
>> with the same pidfile?
Like other things in life, you get what you ask for.
>> Would it be better to create the pidfile in the child process after
>> setsid() and ioctl(), in order to avoid creating the pidfile in case of
>> an error?
>> For reference, the code in misc-utils/uuidd.c uses a more advanced
>> method.
This is not intended to be some default pidfile management mechanism.
Indeed, it cannot be. As my documentation insert clearly states, a pid is
to be saved into a file. Full stop.
> Repeat after me:
> KISS.
Thus, what I am accusing you of stands. You are trying to make this far
more complicated than it needs to be.
Marc.
^ permalink raw reply
* [PATCH] readprofile: put two things that belong together into a single message
From: Benno Schulenberg @ 2025-01-30 15:50 UTC (permalink / raw)
To: util-linux
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
sys-utils/readprofile.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/sys-utils/readprofile.c b/sys-utils/readprofile.c
index 6e6a68b0c..3c200cf4d 100644
--- a/sys-utils/readprofile.c
+++ b/sys-utils/readprofile.c
@@ -99,9 +99,8 @@ static void __attribute__((__noreturn__)) usage(void)
fputs(USAGE_OPTIONS, out);
fprintf(out,
- _(" -m, --mapfile <mapfile> (defaults: \"%s\" and\n"), defaultmap);
- fprintf(out,
- _(" \"%s\")\n"), boot_uname_r_str());
+ _(" -m, --mapfile <mapfile> (defaults: \"%s\" and\n"
+ " \"%s\")\n"), defaultmap, boot_uname_r_str());
fprintf(out,
_(" -p, --profile <pro-file> (default: \"%s\")\n"), defaultpro);
fputs(_(" -M, --multiplier <mult> set the profiling multiplier to <mult>\n"), out);
--
2.48.1
^ permalink raw reply related
* [PATCH] lsmem: make an error message identical to one used in seven other places
From: Benno Schulenberg @ 2025-01-30 14:27 UTC (permalink / raw)
To: util-linux
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
sys-utils/lsmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sys-utils/lsmem.c b/sys-utils/lsmem.c
index c9851e98c..94150e49d 100644
--- a/sys-utils/lsmem.c
+++ b/sys-utils/lsmem.c
@@ -713,7 +713,7 @@ int main(int argc, char **argv)
cl = scols_table_new_column(lsmem->table, ci->name, ci->whint, ci->flags);
if (!cl)
- err(EXIT_FAILURE, _("Failed to initialize output column"));
+ err(EXIT_FAILURE, _("failed to initialize output column"));
if (lsmem->json) {
int id = get_column_id(i);
--
2.48.1
^ permalink raw reply related
* [PATCH] logger: grammarize the description of --socket-errors in the man page
From: Benno Schulenberg @ 2025-01-30 14:11 UTC (permalink / raw)
To: util-linux
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
misc-utils/logger.1.adoc | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/misc-utils/logger.1.adoc b/misc-utils/logger.1.adoc
index 1a5b4310a..a20736a3d 100644
--- a/misc-utils/logger.1.adoc
+++ b/misc-utils/logger.1.adoc
@@ -163,9 +163,15 @@ Most receivers accept messages larger than 1KiB over any type of syslog protocol
Note: the message-size limit limits the overall message size, including the syslog header. Header sizes vary depending on the selected options and the hostname length. As a rule of thumb, headers are usually not longer than 50 to 80 characters. When selecting a maximum message size, it is important to ensure that the receiver supports the max size as well, otherwise messages may become truncated. Again, as a rule of thumb two to four KiB message size should generally be OK, whereas anything larger should be verified to work.
*--socket-errors* __mode__::
-Print errors about Unix socket connections. The _mode_ can be a value of *off*, *on*, or *auto*. When the mode is *auto*, then *logger* will detect if the init process is *systemd*(1), and if so assumption is made _/dev/log_ can be used early at boot. Other init systems lack of _/dev/log_ will not cause errors that is identical with messaging using *openlog*(3) system call. The *logger*(1) before version 2.26 used *openlog*(3), and hence was unable to detected loss of messages sent to Unix sockets.
+Print errors about Unix socket connections. The _mode_ can be *on*, *off*, or *auto*.
+When the mode is *auto* (the default), then *logger* will detect if the init process
+is *systemd*(1), and if so, the assumption is made that _/dev/log_ can be used early
+at boot. The lack of _/dev/log_ on other init systems will not cause errors, just as
+when using the *openlog*(3) system call. The *logger*(1) before version 2.26 used
+*openlog*(3), and thus was unable to detect the loss of messages sent to Unix sockets.
+
-The default mode is *auto*. When errors are not enabled lost messages are not communicated and will result to successful exit status of *logger*(1) invocation.
+When errors are not enabled, lost messages are not communicated and will result in a
+successful exit status of *logger*(1).
*-T*, *--tcp*::
Use stream (TCP) only. By default the connection is tried to the _syslog-conn_ port defined in _/etc/services_, which is often _601_.
--
2.48.1
^ permalink raw reply related
* Re: [PATCH] logger: do not show arguments of --socket-errors as optional in --help
From: Benno Schulenberg @ 2025-01-30 14:10 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
In-Reply-To: <vp3yphm7y73xe4t3clnykrsz3wxvq3mkvmpjybdonz7ypoj3qo@id5gpz6wq4rp>
[-- Attachment #1.1: Type: text/plain, Size: 824 bytes --]
Op 29-01-2025 om 13:32 schreef Karel Zak:
> On Mon, Jan 27, 2025 at 12:08:25PM GMT, Benno Schulenberg wrote:
>> - fputs(_(" --socket-errors[=<on|off|auto>]\n"
>> + fputs(_(" --socket-errors on|off|auto\n"
>> " print connection errors when using Unix sockets\n"), out);
>
> I don't have a strong opinion about it, but in other places we see
> something like:
>
> --socket-errors <mode> print connection errors when using Unix sockets (on, off or auto)
When there are just a few possible argument values, I prefer to list
them directly after the option -- it saves having to interpret words
like "mode", and then looking for the possible values further down.
It also makes it a little less likely that translators mistakenly
translate these values.
Benno
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: License Combination: LGPL and BSD-4-Clause
From: Carsten Emde @ 2025-01-30 13:04 UTC (permalink / raw)
To: Karel Zak, Mario; +Cc: dave, kerolasa, util-linux
In-Reply-To: <4p7kqcztg6c2qoi5ottk4tfn6zjcm6xppe7fayrdbczrf2xxop@fsmmib2v74cy>
Karel,
Mario,
> [..]
> You're absolutely right—the BSD-4-Clause (with the advertising clause)
> is GPL-incompatible, which complicates things when mixing it with LGPL
> code. However, since the LGPL header file includes only trivial inline
> functions (such as memory allocation and linked list utilities), the
> impact on the binary's final license is likely minimal. Here’s why:
Another opinion:
In 1999, Berkeley University stated:
July 22, 1999
To All Licensees, Distributors of Any Version of BSD:
As you know, certain of the Berkeley Software Distribution ("BSD")
source code files require that further distributions of products
containing all or portions of the software, acknowledge within their
advertising materials that such products contain software developed by
UC Berkeley and its contributors.
Specifically, the provision reads:
* 3. All advertising materials mentioning features or use of
this software
* must display the following acknowledgement:
* This product includes software developed by the
University of
* California, Berkeley and its contributors."
Effective immediately, licensees and distributors are no longer
required to include the acknowledgement within advertising materials.
Accordingly, the foregoing paragraph of those BSD Unix files containing
it is hereby deleted in its entirety.
William Hoskins
Director, Office of Technology Licensing
University of California, Berkeley
The original link
(ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change) is no
longer reachable, but the document is cited at various places on the
Internet, among other here -> https://www.freebsd.org/copyright/license/.
We have decided to add the following section to the disclosure material
we provide along with util-linux:
"The original Berkeley University 4-clause license is now referred to as
BSD-4-Clause-UC (https://spdx.org/licenses/BSD-4-Clause-UC.html). Since
this software was continuously maintained after Berkeley University's
disclaimer of the acknowledgment clause, it is assumed to be licensed
under BSD-4-clause-UC. Therefore, no acknowledgment is granted and the
license is considered compatible with GPL/LGPL licenses."
Thanks
-Carsten
--
Carsten Emde, OSADL
www.osadl.org
C.Emde@osadl.org
^ permalink raw reply
* Re: License Combination: LGPL and BSD-4-Clause
From: Karel Zak @ 2025-01-30 10:50 UTC (permalink / raw)
To: Mario; +Cc: util-linux, dave, kerolasa
In-Reply-To: <CAFksh4PZbS_+t7QrOQB++xY_1cYc6Fx-4O1f6MPX3VCTf4-ijQ@mail.gmail.com>
On Wed, Jan 22, 2025 at 11:34:50AM GMT, Mario wrote:
> The file text-utils/hexdump-parse.c is licensed under the BSD-4-Clause license.
> This file includes the header file include/xalloc.h, which is licensed
> under the LGPL.
I will attempt to change the license of xalloc.{c,h} and colors.{c,h}
to public domain, but this will depend on the other authors. It does
not make sense to use any other license for these commonly used files.
The issue lies with list.h (GPL), which we have already used in old
BSD-based tools such as hexdump, kill, and logger.
> According to the GNU licence compatibility list
> (https://www.gnu.org/licenses/license-list.html.en#OriginalBSD),
> this combination of licenses is not allowed.
>
> I would like to know:
>
> How can the resulting binary from this combination be used in a
> license-compliant manner?
Well, ChatGPT has some interesting notes about it:
You're absolutely right—the BSD-4-Clause (with the advertising clause)
is GPL-incompatible, which complicates things when mixing it with LGPL
code. However, since the LGPL header file includes only trivial inline
functions (such as memory allocation and linked list utilities), the
impact on the binary's final license is likely minimal. Here’s why:
Trivial Inline Functions & LGPL Exception
The LGPL allows using inline functions and macros in headers
without imposing LGPL on the entire binary, provided they are
generic and not substantial parts of the program’s logic.
Many projects, including the GNU C Library (glibc), use
LGPL-licensed headers, and applications linking to them are
not automatically subject to LGPL.
BSD-4-Clause Licensing Remains for the Main Code
Since your core program logic remains under BSD-4-Clause and
the LGPL-covered header only provides minor utilities, your
program is still primarily BSD-4-Clause. The advertising
clause does create GPL/LGPL incompatibility for direct
combination, but since the inline functions are trivial, it's
unlikely they trigger a full LGPL conversion.
How to Handle the License Clarification:
If You Want to Be Safe:
Replace the LGPL header with a BSD-compatible alternative
(e.g., a public domain or MIT-licensed equivalent). If
possible, move any non-trivial inline functions into a
separate .c file and dynamically link them under LGPL.
If Keeping It As-Is:
Clarify in the documentation that the main program is
BSD-4-Clause but includes minor LGPL-covered inline functions.
Users should be informed that these inline functions come from
LGPL code, but their triviality does not relicense the binary.
> Are there any possible solutions or workarounds to resolve the license
> incompatibility?
I will make an effort to address this issue in the next major release.
We have been gradually resolving the licensing confusion over the past
few years.
For now, from my point of view, hexdump is still BSD-4-Clause licensed
as LGPL is used for trivial wrappers like err-on-malloc, etc.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH V2] blkid: allow up to 64k erofs block sizes
From: Karel Zak @ 2025-01-30 9:49 UTC (permalink / raw)
To: Gao Xiang; +Cc: Eric Sandeen, util-linux
In-Reply-To: <Z5UBH6G7Af9QyqZx@debian>
On Sat, Jan 25, 2025 at 11:19:59PM GMT, Gao Xiang wrote:
> On Fri, Jan 24, 2025 at 08:37:12AM -0600, Eric Sandeen wrote:
> > Today, mkfs.erofs defaults to page size for block size, but blkid
> > does not recognize this. Increase the limit to 64k.
> >
> > Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>
> Reviewed-by: Gao Xiang <xiang@kernel.org>
Applied, thanks!
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] Fix --disable-widechar compile warnings
From: Karel Zak @ 2025-01-30 9:47 UTC (permalink / raw)
To: Marc Aurèle La France; +Cc: util-linux
In-Reply-To: <014dda0b-0d83-64b0-e0b0-366559fed323@tuyoix.net>
On Sun, Jan 26, 2025 at 10:38:52AM GMT, Marc Aurèle La France wrote:
> Fix warnings when compiling without wide char support.
Applied, thanks.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] Add setsid option to save child process id
From: Marc Aurèle La France @ 2025-01-29 16:57 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
In-Reply-To: <ez4oc4bocqcilq36ncfjusirdkmt6jkpfvaakrx5qcslzoqj6f@wxu57ze7zutk>
On Wed, 2025-Jan-29, Karel Zak wrote:
> On Sun, Jan 26, 2025 at 10:40:19AM GMT, Marc Aurèle La France wrote:
>> Add an option to save the child's pid into a file.
>> @@ -105,6 +115,16 @@ int main(int argc, char **argv)
>> break;
>> default:
>> /* parent */
>> + if (pidpath) {
>> + pidfile = fopen(pidpath, "w");
>> + if (pidfile == NULL)
>> + warn(_("cannot open pidfile %s"),
>> + pidpath);
>> + else {
>> + fprintf(pidfile, "%d\n", pid);
>> + fclose(pidfile);
>> + }
>> + }
>> if (!status)
>> return EXIT_SUCCESS;
>> if (wait(&status) != pid)
> What is the intended use-case for this feature?
To put various utilities (ping, tcpdump, ad nauseam) in the background and
have a simple way of controlling each instance individually.
> I am unsure if this implementation is too simplistic. It seems that
> the file is not deleted after the child process exits. Furthermore,
> what would happen if we call multiple setsid instances with the same
> pidfile? Would it be better to create the pidfile in the child process
> after setsid() and ioctl(), in order to avoid creating the
> pidfile in case of an error?
> For reference, the code in misc-utils/uuidd.c uses a more advanced
> method.
Repeat after me:
KISS.
Marc.
^ permalink raw reply
* Re: [PATCH] blkid: say "override" instead of "overwrite" in the --help text
From: Karel Zak @ 2025-01-29 12:32 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux
In-Reply-To: <20250127152144.11446-1-bensberg@telfort.nl>
On Mon, Jan 27, 2025 at 04:21:44PM GMT, Benno Schulenberg wrote:
> misc-utils/blkid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] logger: do not show arguments of --socket-errors as optional in --help
From: Karel Zak @ 2025-01-29 12:32 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux
In-Reply-To: <20250127110825.7219-1-bensberg@telfort.nl>
On Mon, Jan 27, 2025 at 12:08:25PM GMT, Benno Schulenberg wrote:
> misc-utils/logger.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
>
> diff --git a/misc-utils/logger.c b/misc-utils/logger.c
> index f696287d7..bcdff0614 100644
> --- a/misc-utils/logger.c
> +++ b/misc-utils/logger.c
> @@ -1101,7 +1101,7 @@ static void __attribute__((__noreturn__)) usage(void)
> fputs(_(" --sd-param <data> rfc5424 structured data name=value\n"), out);
> fputs(_(" --msgid <msgid> set rfc5424 message id field\n"), out);
> fputs(_(" -u, --socket <socket> write to this Unix socket\n"), out);
> - fputs(_(" --socket-errors[=<on|off|auto>]\n"
> + fputs(_(" --socket-errors on|off|auto\n"
> " print connection errors when using Unix sockets\n"), out);
I don't have a strong opinion about it, but in other places we see
something like:
--socket-errors <mode> print connection errors when using Unix sockets (on, off or auto)
Note: I have also fixed the man page where we had [=mode] as well.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] lscpu: make three column descriptions more grammatical
From: Karel Zak @ 2025-01-29 12:22 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux
In-Reply-To: <20250126110924.5611-1-bensberg@telfort.nl>
On Sun, Jan 26, 2025 at 12:09:24PM GMT, Benno Schulenberg wrote:
> sys-utils/lscpu.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Applied, thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] Add setsid option to save child process id
From: Karel Zak @ 2025-01-29 12:16 UTC (permalink / raw)
To: Marc Aurèle La France; +Cc: util-linux
In-Reply-To: <be555f23-ae5e-f7d1-9b7c-28f4191664e7@tuyoix.net>
Hi Marc,
On Sun, Jan 26, 2025 at 10:40:19AM GMT, Marc Aurèle La France wrote:
> Add an option to save the child's pid into a file.
we usually use Signed-off-by: line in the commit messages.
> @@ -105,6 +115,16 @@ int main(int argc, char **argv)
> break;
> default:
> /* parent */
> + if (pidpath) {
> + pidfile = fopen(pidpath, "w");
> + if (pidfile == NULL)
> + warn(_("cannot open pidfile %s"),
> + pidpath);
> + else {
> + fprintf(pidfile, "%d\n", pid);
> + fclose(pidfile);
> + }
> + }
> if (!status)
> return EXIT_SUCCESS;
> if (wait(&status) != pid)
What is the intended use-case for this feature?
I am unsure if this implementation is too simplistic. It seems that
the file is not deleted after the child process exits. Furthermore,
what would happen if we call multiple setsid instances with the same
pidfile? Would it be better to create the pidfile in the child process
after setsid() and ioctl(), in order to avoid creating the
pidfile in case of an error?
For reference, the code in misc-utils/uuidd.c uses a more advanced
method.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH] blkid: say "override" instead of "overwrite" in the --help text
From: Benno Schulenberg @ 2025-01-27 15:21 UTC (permalink / raw)
To: util-linux
The `blkid` tool does not write anything to the probed device, so
seeing "overwrite" in the usage text was somewhat disconcerting.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
misc-utils/blkid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/misc-utils/blkid.c b/misc-utils/blkid.c
index d5fe4f1fa..63e61b5fa 100644
--- a/misc-utils/blkid.c
+++ b/misc-utils/blkid.c
@@ -96,7 +96,7 @@ static void __attribute__((__noreturn__)) usage(void)
fputs(_( " -p, --probe low-level superblocks probing (bypass cache)\n"), out);
fputs(_( " -i, --info gather information about I/O limits\n"), out);
fputs(_( " -H, --hint <value> set hint for probing function\n"), out);
- fputs(_( " -S, --size <size> overwrite device size\n"), out);
+ fputs(_( " -S, --size <size> override device size\n"), out);
fputs(_( " -O, --offset <offset> probe at the given offset\n"), out);
fputs(_( " -u, --usages <list> filter by \"usage\" (e.g. -u filesystem,raid)\n"), out);
fputs(_( " -n, --match-types <list> filter by filesystem type (e.g. -n vfat,ext3)\n"), out);
--
2.48.1
^ permalink raw reply related
* Re: [PATCH v2] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support
From: Ivan Kokshaysky @ 2025-01-27 13:27 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Eric W. Biederman, Maciej W. Rozycki, Arnd Bergmann,
Richard Henderson, Matt Turner, Kees Cook, Paul E. McKenney,
linux-alpha, linux-mm, linux-kernel, Michael Cree, Sam James,
Geert Uytterhoeven, Michael Karcher, Chris Hofstaedtler,
util-linux, linux-mips, loongarch
In-Reply-To: <5cff63bf0fc9e62772fb24bc919c591acbd10d53.camel@physik.fu-berlin.de>
On Sun, Jan 26, 2025 at 06:15:43PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Eric,
>
> On Sat, 2025-01-18 at 11:35 +0100, Ivan Kokshaysky wrote:
> > On Sun, Jan 12, 2025 at 11:39:01PM -0600, Eric W. Biederman wrote:
> > ...
> > > --- a/arch/alpha/include/asm/pgtable.h
> > > +++ b/arch/alpha/include/asm/pgtable.h
> > > @@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
> > >
> > > extern void paging_init(void);
> > >
> > > -/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT. */
> > > +/* We have our own get_unmapped_area */
> > > #define HAVE_ARCH_UNMAPPED_AREA
> >
> > Just remove the definition. As the comment suggests, the only reason
> > it exists is ADDR_LIMIT_32BIT, which is gone.
> >
> > > --- a/arch/alpha/kernel/osf_sys.c
> > > +++ b/arch/alpha/kernel/osf_sys.c
> > > @@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
> > > return ret;
> > > }
> > >
> > > -/* Get an address range which is currently unmapped. Similar to the
> > > - generic version except that we know how to honor ADDR_LIMIT_32BIT. */
> > > +/* Get an address range which is currently unmapped. */
> > >
> > > static unsigned long
> > > arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
> > > @@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
> > > unsigned long len, unsigned long pgoff,
> > > unsigned long flags, vm_flags_t vm_flags)
> > > {
> > > - unsigned long limit;
> > > -
> > > - /* "32 bit" actually means 31 bit, since pointers sign extend. */
> > > - if (current->personality & ADDR_LIMIT_32BIT)
> > > - limit = 0x80000000;
> > > - else
> > > - limit = TASK_SIZE;
> > > + unsigned long limit = TASK_SIZE;
> > >
> > > if (len > limit)
> > > return -ENOMEM;
> >
> > Likewise, just remove these functions. The generic_get_unmapped_area()
> > works fine, tested on up1500.
>
> Can you send a follow-up integrating those changes? It would be good if
> SET_PERSONALITY() could be fixed on alpha for v6.14.
Oh, the changes I proposed are mere cleanup suggestions.
The original patch would do just fine.
Ivan.
^ permalink raw reply
* [PATCH] logger: do not show arguments of --socket-errors as optional in --help
From: Benno Schulenberg @ 2025-01-27 11:08 UTC (permalink / raw)
To: util-linux
Also, show them without angular brackets, as they are literal values.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
misc-utils/logger.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/misc-utils/logger.c b/misc-utils/logger.c
index f696287d7..bcdff0614 100644
--- a/misc-utils/logger.c
+++ b/misc-utils/logger.c
@@ -1101,7 +1101,7 @@ static void __attribute__((__noreturn__)) usage(void)
fputs(_(" --sd-param <data> rfc5424 structured data name=value\n"), out);
fputs(_(" --msgid <msgid> set rfc5424 message id field\n"), out);
fputs(_(" -u, --socket <socket> write to this Unix socket\n"), out);
- fputs(_(" --socket-errors[=<on|off|auto>]\n"
+ fputs(_(" --socket-errors on|off|auto\n"
" print connection errors when using Unix sockets\n"), out);
#ifdef HAVE_LIBSYSTEMD
fputs(_(" --journald[=<file>] write journald entry\n"), out);
--
2.48.1
^ permalink raw reply related
* Re: lscpu uses unfitting "MHz" in frequency scaling item
From: Karel Zak @ 2025-01-27 10:10 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux
In-Reply-To: <3a525c3b-ddb1-48c9-887a-f34705415fec@telfort.nl>
On Sun, Jan 26, 2025 at 11:52:25AM GMT, Benno Schulenberg wrote:
> Since commit 9b9e4f5d06be55f4b9e1a52b448055933df92c6b
> from four years ago, lscpu lists also an item like this:
>
> CPU(s) scaling MHz: 61%
>
> The printed value is a percentage, not a frequency, so the
> "MHz" should not be there, I think -- the percentage would
> be the same no matter whether the frequencies (in other items)
> are shown in kHz or MHz or GHz.
lscpu only uses MHz (as well as the kernel in /sys), but you are
correct that "CPU(s) frequency scaling" sounds better.
> I would provide a patch, but the message occurs in a dozen
> or more tests. And probably the column name needs to be
> changed too, from SCALMHZ% to FREQSCAL% or SCALING%?
I am doubtful that we can alter column names. The usual recommendation
is to use "-o <colname>" to obtain output for the script. Changing a
column name would cause a backwardly incompatible modification. It may
be feasible to introduce a column alias, but I am uncertain if it
would be worthwhile.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: Bug#1094283: util-linux: dmesg shows color when /etc/terminal-colors.d/disable is present (and no override in xdg locations)
From: Chris Hofstaedtler @ 2025-01-26 22:19 UTC (permalink / raw)
To: Thomas Weißschuh; +Cc: util-linux, Axel, 1094283
In-Reply-To: <173791554931.11406.7776184826380347386.reportbug@teal.home>
Hello Thomas,
it appears commit 4bdf22803f9a41329694e0c3c82189635dccdcd0 breaks
disabling colors using the documented mechanism of touching
/etc/terminal-colors.d/dmesg.disable. See below for a user report.
On Sun, Jan 26, 2025 at 07:19:09PM +0100, Axel wrote:
> Package: util-linux
> Version: 2.40.4-1
>
> Running dmesg after upgrading to trixie started showing color. The manpage
> mentions creating /etc/terminal-colors.d/disable which should disable colors
> for all. Creating the also mentioned /etc/terminal-colors.d/dmesg.disable
> doesn't disable color output also. I had /etc/terminal-colors.d/disable
> configured which did disable colors on -stable.
From what I can tell, the new rc = -ENOENT in colors_readdir
introduced in 4bdf22803f9a41329694e0c3c82189635dccdcd0 bubbles up to
colors_init:
int rc = colors_read_configuration(cc); // calls colors_readdir, now returns -2
if (rc)
cc->mode = UL_COLORMODE_DEFAULT;
else {
Evaluating color scores is skipped, effectively ignoring the
"disable" file.
Could you please take a look?
Reverting 4bdf22803f9a41329694e0c3c82189635dccdcd0 fixes the problem
for me.
Debug output from TERMINAL_COLORS_DEBUG=0xffff ./dmesg
| 321357: termcolors: CONF: terminal is ready (supports 256 colors)
| 321357: termcolors: CONF: reading dir: '/root/.config/terminal-colors.d'
| 321357: termcolors: CONF: reading dir: '/etc/terminal-colors.d'
| 321357: termcolors: CONF: item 'dmesg.disable': score=21 [cur: 0, name(5): dmesg.disable, term(0): (null)]
| 321357: termcolors: CONF: setting 'disable' from 0 -to-> 21
| Colors:
| utilname = 'dmesg'
| termname = 'xterm-256color'
| scheme file = '(null)'
| mode = auto
| has_colors = 1
| disabled = 0
| configured = 1
| cs configured = 0
|
| score disable = 21
| score enable = 0
| score scheme = 0
After reverting 4bdf22803f9a41329694e0c3c82189635dccdcd0:
| 321318: termcolors: CONF: terminal is ready (supports 256 colors)
| 321318: termcolors: CONF: reading dir: '/root/.config/terminal-colors.d'
| 321318: termcolors: CONF: reading dir: '/etc/terminal-colors.d'
| 321318: termcolors: CONF: item 'dmesg.disable': score=21 [cur: 0, name(5): dmesg.disable, term(0): (null)]
| 321318: termcolors: CONF: setting 'disable' from 0 -to-> 21
| Colors:
| utilname = 'dmesg'
| termname = 'xterm-256color'
| scheme file = '(null)'
| mode = never
| has_colors = 0
| disabled = 0
| configured = 1
| cs configured = 0
|
| score disable = 21
| score enable = 0
| score scheme = 0
Thanks,
Chris
^ permalink raw reply
* [PATCH] Add setsid option to save child process id
From: Marc Aurèle La France @ 2025-01-26 17:40 UTC (permalink / raw)
To: util-linux
Add an option to save the child's pid into a file.
Marc.
diff -NRapruz -X /etc/diff.excludes util-linux-2.40.4/sys-utils/setsid.1.adoc devel-2.40.4/sys-utils/setsid.1.adoc
--- util-linux-2.40.4/sys-utils/setsid.1.adoc
+++ devel-2.40.4/sys-utils/setsid.1.adoc
@@ -31,6 +31,9 @@ Always create a new process.
*-w*, *--wait*::
Wait for the execution of the program to end, and return the exit status of this program as the exit status of *setsid*.
+*-p*, *--pidfile* _file_::
+If forked, write the process id of the program to _file_.
+
*-V*, *--version*::
Display version information and exit.
diff -NRapruz -X /etc/diff.excludes util-linux-2.40.4/sys-utils/setsid.c devel-2.40.4/sys-utils/setsid.c
--- util-linux-2.40.4/sys-utils/setsid.c
+++ devel-2.40.4/sys-utils/setsid.c
@@ -14,6 +14,9 @@
*
* 2008-08-20 Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* - if forked, wait on child process and emit its return code.
+ *
+ * 2025-01-25 Marc Aurèle La France <tsi@tuyoix.net>
+ * - If forked, save the child's process id in a file.
*/
#include <getopt.h>
#include <stdio.h>
@@ -39,11 +42,12 @@ static void __attribute__((__noreturn__)) usage(void)
fputs(_("Run a program in a new session.\n"), out);
fputs(USAGE_OPTIONS, out);
- fputs(_(" -c, --ctty set the controlling terminal to the current one\n"), out);
- fputs(_(" -f, --fork always fork\n"), out);
- fputs(_(" -w, --wait wait program to exit, and use the same return\n"), out);
+ fputs(_(" -c, --ctty set the controlling terminal to the current one\n"), out);
+ fputs(_(" -f, --fork always fork\n"), out);
+ fputs(_(" -w, --wait wait program to exit, and use the same return\n"), out);
+ fputs(_(" -p, --pidfile <file> write child pid to <file>\n"), out);
- fprintf(out, USAGE_HELP_OPTIONS(16));
+ fprintf(out, USAGE_HELP_OPTIONS(26));
fprintf(out, USAGE_MAN_TAIL("setsid(1)"));
exit(EXIT_SUCCESS);
@@ -55,14 +59,17 @@ int main(int argc, char **argv)
int ctty = 0;
pid_t pid;
int status = 0;
+ const char *pidpath = NULL;
+ FILE *pidfile;
static const struct option longopts[] = {
- {"ctty", no_argument, NULL, 'c'},
- {"fork", no_argument, NULL, 'f'},
- {"wait", no_argument, NULL, 'w'},
- {"version", no_argument, NULL, 'V'},
- {"help", no_argument, NULL, 'h'},
- {NULL, 0, NULL, 0}
+ {"ctty", no_argument, NULL, 'c'},
+ {"fork", no_argument, NULL, 'f'},
+ {"wait", no_argument, NULL, 'w'},
+ {"pidfile", required_argument, NULL, 'p'},
+ {"version", no_argument, NULL, 'V'},
+ {"help", no_argument, NULL, 'h'},
+ {NULL, 0, NULL, 0}
};
setlocale(LC_ALL, "");
@@ -70,7 +77,7 @@ int main(int argc, char **argv)
textdomain(PACKAGE);
close_stdout_atexit();
- while ((ch = getopt_long(argc, argv, "+Vhcfw", longopts, NULL)) != -1)
+ while ((ch = getopt_long(argc, argv, "+Vhcfp:w", longopts, NULL)) != -1)
switch (ch) {
case 'c':
ctty=1;
@@ -81,6 +88,9 @@ int main(int argc, char **argv)
case 'w':
status = 1;
break;
+ case 'p':
+ pidpath = optarg;
+ break;
case 'h':
usage();
@@ -105,6 +115,16 @@ int main(int argc, char **argv)
break;
default:
/* parent */
+ if (pidpath) {
+ pidfile = fopen(pidpath, "w");
+ if (pidfile == NULL)
+ warn(_("cannot open pidfile %s"),
+ pidpath);
+ else {
+ fprintf(pidfile, "%d\n", pid);
+ fclose(pidfile);
+ }
+ }
if (!status)
return EXIT_SUCCESS;
if (wait(&status) != pid)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox