Your message dated Sun, 26 Jul 2020 22:14:10 +0200
with message-id <[email protected]>
and subject line Re: Bug#965062: systemd: Cannot resolve user name
systemd-network: No such process
has caused the Debian Bug report #965062,
regarding systemd: Cannot resolve user name systemd-network: No such process
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
965062: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965062
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 241-7~deb10u4
Severity: normal
Dear Maintainer,
after upgrading multiple systems from jessie to buster, systemd-networkd
and systemd-resolved no longer start on any of them, both with similar
error messages:
Jul 15 11:42:17 pxe systemd-networkd[327]: Cannot resolve user name
systemd-network: No such process
Jul 15 11:42:18 pxe systemd-resolved[472]: Cannot resolve user name
systemd-resolve: No such process
Both daemons worked fine before the upgrade. googling shows me a number of
reports related to DynamicUsers, but this doesn't seem to apply to this
case, as both users exist in /etc/passwd:
systemd-timesync:x:100:102:systemd Time
Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network
Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
I cannot run reportbug on the affected system, so I removed the
automatically-added info as it would refer to the wrong system.
--- End Message ---
--- Begin Message ---
Hi Marc
Am 25.07.20 um 01:52 schrieb Marc Lehmann:
> On Sun, Jul 19, 2020 at 03:40:41PM +0200, Michael Biebl <[email protected]>
> wrote:
>> Maybe you start with a minimal debian system and turn that bit by bit
>> into a system like the one where you encounter the problem to see which
>> change is causing it.
>
> Unfortunately, I was away for a bit and when I returned some helpful
> person had it set up from scratch, deleting the old installation.
>
> I was told that /var/tmp had wrong permissions (1700 instead of 1777), so
> maybe that was the reason for the problem, although when I manually chmod
> 1700 /var/tmp, I can't reproduce the problem with the fresh setup, either.
Hmm, too bad.
Maybe some other directories had messed up permissions. But I guess we
won't find out now. An strace might have helped with finding that.
> Already sent this one - I don't think resolving the passwd/group entries were
> the problem, something else went wrong, and the problem here is just very
> bad error reporting.
Yeah, very likely. I can image that a permission error was turned into a
rather generic error message when passed up the stack.
> Anyway, I'm sorry to not be able to provide closure here, I did reserve
> the pxe environment for further debugging, but due to circumstances out of
> my control, it has been deleted. A fresh buster setup, not surprisingly,
> works fine.
>
I guess at this point it's probably best to close the bug report as we
don't have enough data to reproduce and fix the issue.
If you run into this again, please reopen or simply let us know, so we
can reopen it for you.
Regards,
Michael
signature.asc
Description: OpenPGP digital signature
--- End Message ---
