Hello dear adduser maintainer(s),

I swear, *every* time I do `adduser user group` I have
to look up on the internet how to make that group available
to that user in a running shell session...

The attached patch adds two phrases to the "Add an existing user
to an existing group" paragraph that tells the reader to use
`newgrp` to achieve that and mentions `newgrp` in the
"SEE ALSO" section.

I'd be glad if you could include this in the man page so I
(and probably others) can stop looking it up on the internet
each time...

Best greetings and thank you for your work on `adduser`.
*t

Hi,

I am totally not sure whether this is appropriate. I agree that this
behavior is a quick of many operating systems, but I don't think that
adduser should begin to document operating system quirks. People might
see this as an issue in adduser, which it isn't.

Greetings
Marc

Hi Marc!

Well, I mean the goal of "adduser user group" is to add a user to a
group... except that - it doesn't. As a user of adduser I'm not really
interested who's fault it is - I just want to get the job done.

At some point I have somehow found out that using some other magic in
addition is necessary. Other users of adduser might not know and just
think that `adduser user group` doesn't work or is broken or ...

As I said - the user doesn't and shouldn't actually need to care where the
blame lies...

So why not give the user a hand to get the job done?
*t

It adds the user to the group. It is not adduser's fault that /etc/group
is just read on login.

That is not magic, it's basic Unix semantic.
in the last release cycle literally days to clean adduser's man pages of
redundant information to make it easier to maintain them. This would be
counterproductive.

Greetings
Marc

P.S.: I keep falling into that trap myself

I think you're confusing what you want done with what is actually done.

The command "adduser foo bar" updates system records to indicate that
user "foo" has membership in supplementary group "bar". The goal of this
command is to update these records, and it ~does~ do this.

The fact that existing shell sessions must be reinitialized is really
just part of how the OS works.

I actually wouldn't rely on "newgrp" too much for this purpose. It may
not work the way you think.

For example, on Debian "newgrp" creates subprocesses instead of
replacing the shell. On some systems, the shell actually is replaced.

Try this...

$ pstree -ps $$
$ newgrp
$ pstree -ps $$

It may illustrate what I'm talking about. You get a subshell, and you
need to exit or logout twice to get out now.

This is the case on my system, which is older… may have been updated.

In light of this, I think "newgrp" is more useful for temporarily
assuming a group identity to do some stuff and then backing out to your
login identity.

You can tell users to run "newgrp" when you add them to a group, but
they'll have to do this in every open session. Also, they may be
confused if they exit the new shell and they go back to their old
identity.

The way to avoid any confusion, I've found, is just to tell the user to
"fully logout and log back in" and then go about their business.

I don't think the adduser man page should make mention of newgrp. We
don't own that tool (the "login" package does).

Best,

To follow up on what I said here, I also want to address the patch you
provided as this may be different than what you think as well.

If you do…

# adduser foo bar

… you have added user "foo" to group "bar" where the latter is now
a supplementary group for the former (i.e., you've updated system
records).

If the user now runs "newgrp bar", the user will assume "bar" as their
primary group. This is ~not~ the same as having the group appended to
their supplementary groups in their current shell session.

There are other differences, but "log out & log in" remains the best and
most complete and correct advice for this situation. It provides the
most predictable result for the user.

Hi Jason,

thanks for presenting your arguments!

The man page says:

    Add an existing user to an existing group
        If called with two non-option arguments, adduser will add an
        existing user to an existing group.

It doesn't talk about anything of what you've written above. The canonical
tool to verify whether a user is member of a group is `id`:

     $ sudo adduser joe fancyusers
     $ id
     uid=1000(joe) gid=1000(joe)
     groups=1000(joe)

which tells me that adduser in fact did *not* add the user to the group.

In my opinion the goal of Debian is to serve its users. When the manpage
is quiet about why after adding a user to a group the user is still not
member of the group then that is *not* serving the user IMO.

I can agree to that.

So let's point the user to some explanation instead of not doing what a
user without any additional experience would expect and not saying
anything about the problem that `adduser user group` has.

The adduser man page doesn't own anything. It lives in a context, which is
Unix I'd guess, and can try to be useful in that context. So if
adduser behaves in some unexpected way when interacting with Unix then
it should tell the user IMO.

?
*t

I agree with that

The question then is whether or not we want the man page to be more
helpful in describing the effects of this use case.

Maybe it could say something like this…

This is a minimal change that at least makes note of something that may
be surprising to a person who has limited familiarity with how Debian
works.

Would this type of change help?

Marc, do you think this is reasonable?

I am still not a fan. That additional language needs to be maintained,
translated, proofread, and discussed. I'd rather not having to do that.

Greetings
Marc

I am in agreement with Marc here.

I have not been as involved, so my opinion is of minimal value.

Still, I think there is a limit to how helpful a manpage can be. There
has to be a stopping point somewhere, with a general expectation that
users will be at least somewhat familiar with their system.

When user account attributes (of many types) are modified, the
expectation is generally that a user logs in again to have those changes
take effect. This is just "one of those things" you know after dealing
with Debian (or any other distro) for even a little while.

Best,

So I suggest to add just *one* *single* phrase:

"The added group will not be visible in current user sessions"

Is that an acceptable compromise between "the user is left completely in
the dark" and "maintaining additional words adds too much of a workload"?
*t

There will be a bug report "please make added groups visible in current
user sessions" since this sentence suggests that it's a design decision
in adduser.

"Leaving people in the dark" is suggesting that the adduser maintainers
act in bad faith. We Don't.

Because if there is no desire to improve the situtation for the user then
there is no point discussing semantics of words. This discussion has been
going on for a dozen of posts with me trying to improve the situtation of
the `adduser` user but I have yet to see a constructive reply from you
Marc - constructive in the sense "yes this is a problem and yes I want to
improve the life of an `adduser` user".

So if there's no desire to improve the adduser manpage or adduser with
respect to the problem at hand then there's no point in spending time
discussing it, or am I misunderstanding something?

I do understand your concern Marc, that any byte published is a byte that
needs to be maintained. But if that is the argument that tops all the
others then no change is possible.

Again: if there's no will to change anything and if that is the top
argument then there's no point in further discussion.
*t

Hello Tomas,
hello Marc,
hello Jason,
sorry for comming in late into the discussion, I was offline for some
days.

Regarding the translations:
If desired, I can quickly poll all active translators for the update.
Preferrably this week, as I have some time.

Regarding the proposal:
I agree that a man page for a command should not be a general
tutorial. But I would not see this as strict - if there is a more
general misconception or something helpful for the users, I would
personally add it. And the last proposal "A logged in user will need
to log out and log back in for the change to take effect." sounded
quite sensible to me, not overreaching.

But in the end, of course, it is Marcs decision.

Greetings

          Helge

We believe that the bug you reported is fixed in the latest version of
adduser, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1103776@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marc Haber <mh+debian-packages@zugschlus.de> (supplier of updated adduser package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 17 Jun 2026 22:36:50 +0200
Source: adduser
Architecture: source
Version: 3.157
Distribution: unstable
Urgency: medium
Maintainer: Debian Adduser Developers <adduser@packages.debian.org>
Changed-By: Marc Haber <mh+debian-packages@zugschlus.de>
Closes: 472820 1101457 1103776 1118210 1133696 1137602 1137603
Changes:
 adduser (3.157) unstable; urgency=medium
 .
   [ Marc Haber ]
   * add script that runs the testsuite without autopkgtest
     (Closes: #1101457)
   * add a NOTE to adduser.8 regarding group membership (Closes: #1103776)
   * implement adduser --force-home.
     Thanks to Jeff Hanson (Closes: #472820)
   * Add new Romanian program and man page translation.
     Thanks to Remus-Gabriel Chelu (Closes: #1137603, #1137602)
   * update dutch program translation.
     Thanks to Frans Spiesschaert (Closes: #1118210, #1133696)
 .
   [ Dustin Kirkland ]
   * Add support for encrypting home directories
     * adduser: Add --encrypt-home option, which calls ecryptfs-setup-private
       for the hard work.
     * doc/adduser.8: document the --encrypt-home option
     * debian/control: suggest ecryptfs-utils >= 67-1
     * deluser: remove all of /var/lib/ecryptfs/$user with --remove-home
 .
   [ Mateus Rodrigues de Morais ]
   * Add encrypted home tests with isolation-machine restriction
Checksums-Sha1:
 b013d8fc97493cdf5e8cf4155155124251e26609 1811 adduser_3.157.dsc
 c1dca503370a1be803518247a2a27f85b0fcb114 361112 adduser_3.157.tar.xz
Checksums-Sha256:
 a3e806b5e4861c8d1bef55ba184affeade86bd4acf377c7877a63f68ec0c8f56 1811 adduser_3.157.dsc
 78f64b02b2962437ef6d371126e922e71fe5024f943bef7240b6178d74d0a0e9 361112 adduser_3.157.tar.xz
Files:
 5393614c69f578219ca8e41bc8da9db9 1811 admin important adduser_3.157.dsc
 f3bf3ff2c9543a952d28f0f7cd3b494b 361112 admin important adduser_3.157.tar.xz
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE6QL5UJ/L0pcuNEbjj3cgEwEyBEIFAmozBnwACgkQj3cgEwEy
BEImHg/8Dldd0Y8goqdMtiy05SQOZHtfhHj5W4lAjjzrOwdFR57LCG3yovNcFnmS
HYV39yd9NPkGY4/N2UKnrpeTvpVXGzjur1YNZlAj/wj1OaxXzZAfDj20NxENEFpm
OdicbAcF9vddB2tdG+wdYzg7wOAmWkGBg65IPbxzA29Ki+etRoyb/az5TVQsGpCI
Uy40sbEnGLQ4VGcRroPEiZkLzo+MEwKCSVkamW6Wil3ZsVBLIaJfrWOewU38cGeW
YLvVvC1pGWGyNtsztz5dLfAo3cNsisoq4ZWFzJFmG60Ic9D0fQ3Ml+QgmU6QMRpr
Gry9rHGMfLjWR+a3m026z+a3EzSYQbyQopqrg5OCWL11BjLZTkDg0cxC/ebuKEBE
cnl3DU+WZ0GSlF3LhKIBwuHv6Eoppaq1655/JdWhp70gNNGVMIxsR9SH8S/7A2OT
apNTWv5ddt3lag9iiRYBwAI6aoXHaobOGN4/gC33RAl4H8qJP0oWgQsI5m9t0o+V
TqQ4KlWU/qFjDfjC4BYy07flPa2XEMDP/UhI6mxzFhel9a8+8ed+F0GUmyvjTg8N
wbqBleLLiAjIMEwAPIMbe5Pf91ulsffXGTe4PKRvj0nvoIcAv5aui1SO+9hH5fLr
tnvonWtY8/FcBQLD+zEO7YWpu5EXOj4wrBYgDW5cz+8Udch3Xnw=
=uajK
-----END PGP SIGNATURE-----