Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1154132 > unrolled thread

Bug#1041014: systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1041014: systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied "Al Ma" <alma0@ro.ru> - 2023-07-14 05:50 +0200
    Bug#1041014: marked as done (systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied) Michael Biebl <biebl@debian.org> - 2023-07-14 08:20 +0200
      Bug#1041014: marked as done (systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied) AlMa <AlMa0@ro.ru> - 2023-07-14 14:50 +0200
        Bug#1041014: marked as done (systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied) Michael Biebl <biebl@debian.org> - 2023-07-14 15:00 +0200
    Bug#1041014: systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied AlMa <AlMa0@ro.ru> - 2023-07-17 12:40 +0200
    Bug#1041014: systemd-timesyncd: data collected by reportbug, new journal Michael Biebl <biebl@debian.org> - 2023-07-22 22:10 +0200
      Bug#1041014: systemd-timesyncd: data collected by reportbug, new journal "Al Ma" <alma0@ro.ru> - 2023-07-22 23:10 +0200
    Bug#1041014: Permission of /lib64 were wrong "Алекс ______" <a_l_e_x_0@ro.ru> - 2023-07-29 00:20 +0200

#1154132 — Bug#1041014: systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied

[Multipart message — attachments visible in raw view] — view raw

Package: systemd-timesyncd
Version: 252.6-1
`systemctl restart systemd-timesyncd` says that the control process exited with error code. Status says, "Failed at step EXEC spawning /lib/systemd/systemd-timesyncd: Permission denied".
In the `output of journal  -xeu systemd-timesyncd.service` we see
systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied
systemd-timesyncd.service: Failed at step EXEC spawning /lib/systemd/systemd-timesyncd: Permission dienied
…
The error number returned by this process is ERRNO.
However,
-rwxr-xr-x 1 root root 55520 28. Feb 12:15 /lib/systemd/system-timesyncd
The error appeared after upgrading from Debian 11 to Debian 12.

[toc] | [next] | [standalone]

#1154138 — Bug#1041014: marked as done (systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied)

[Multipart message — attachments visible in raw view] — view raw

Fwiw, last time someone posted a similar message, he had messed up 
permissions of the / file system.

Also check /tmp and /var/tmp directory permission and make sure nothing 
like selinux is interfering.

In any case, I'm pretty sure it's not a systemd issue itself.

[toc] | [prev] | [next] | [standalone]

#1154172 — Bug#1041014: marked as done (systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied)

reopen 1041014
thanks

Michael, thanks for a quick reaction.
It's not he who messed up but probably the upgrade process from Debian 
11 to Debian 12.  The system is not booting up properly (gdm3 fails to 
start and other issues), and the message concerning systemd-timesyncd is 
the earliest one in the log that might indicate a related problem.  As 
for bugreport, it's a bit troublesome to install it, run it, copy the 
output to a working machine, anonymize the output, and post it.  I'll 
try to do it, but as this would take long, it won't happen today.  Here 
are the permissions (manually retyped after booting into single mode and 
reading the screen output):

# ls -la /
insgesamt 72
drwxr-xr-x  18 root root  4096 14. Jul 13:56 .
drwxr-xr-x  18 root root  4096 14. Jul 13:56 ..
lrwxrwxrwx   1 root root     7 13. Jul 16:41 bin -> /usr/bin
…

# ls -la /tmp
insgesamt 4
drwxrwxrwt  8 root root  160 14. Jul 14:17 .
drwxr-xr-x 18 root root 4096 14. Jul 13:56 ..
drwxrwxrwt  2 root root   40 14. Jul 13:46 .font-unix
…

# ls -la /var/tmp
insgesamt 28
drwxrwxrwt  5 root     root     12288 14. Jul 14:17 .
drwxr-xr-x 12 root     root      4096  3. Dez 2021  ..
drwx------  2 username username  4096  5. Mär 16:57 audacity-username
…

libselinux1 version 3.4-1+b6 is installed.  I've re-installed it now. 
Attempt to remove?

After restarting NetworkManager and getting network, running `systemctl 
restart systemd-timesyncd` ended up with "systemd-timesyncd.service: 
Start request repeated too quickly." followed by 
"systemd-timesyncd.service: Failed with result 'exit-code'." in the 
output of `journalctl -xeu systemd-timesyncd.service`.

If you are think that the original problem is not related to systemd, 
please feel free to reassign to another package if you are sure. (Which 
one? I don't know. Probably, a boot-related or an installation-related one.)

As for the bug(s) in systemd itself, what it should do in any case is 
improve the error messages. The aforementioned messages such as "The 
error number returned by this process is ERRNO." and 
"systemd-timesyncd.service: Failed with result 'exit-code'." are bogus 
and not really helpful.  Not the generic strings "ERRNO" and 
"'exit-code'" should be output but specific symbolic error names (e.g., 
EPERM, ENOENT, EIO, …) or numerical values.  If such specific symbolic 
error names and numerical values are unavailable, the aforementioned 
messages should be simplified (e.g., "An error was returned by this 
process." and "systemd-timesyncd.service: Failed and exited." if this is 
really what happened there.)

Gratefully,
AlMa

On 14.07.23 08:12, Michael Biebl wrote:
> Fwiw, last time someone posted a similar message, he had messed up 
> permissions of the / file system.
> 
> Also check /tmp and /var/tmp directory permission and make sure nothing 
> like selinux is interfering.

[toc] | [prev] | [next] | [standalone]

#1154178 — Bug#1041014: marked as done (systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied)

[Multipart message — attachments visible in raw view] — view raw

Am 14.07.23 um 14:43 schrieb AlMa:
> reopen 1041014
> thanks
> 
> Michael, thanks for a quick reaction.
> It's not he who messed up but probably the upgrade process from Debian 
> 11 to Debian 12.  The system is not booting up properly (gdm3 fails to 
> start and other issues), and the message concerning systemd-timesyncd is 

It's possible that the upgrade process between 11 and 12 did not run 
properly and something was broken.

As I wrote, the output from systemd doesn't look like the root cause of 
your issues but only a symptom.

Hard to say with basically zero information.

[toc] | [prev] | [next] | [standalone]

#1154593

typo above:

"screenshot" is highlighted
→
“timesyncd” is highlighted

[toc] | [prev] | [next] | [standalone]

#1155363 — Bug#1041014: systemd-timesyncd: data collected by reportbug, new journal

[Multipart message — attachments visible in raw view] — view raw

The logs so far do not reveal anything out of the ordinary.

Please start /lib/systemd/systemd-timesyncd directly (as root, from the 
command line).
If that fails as well, please run strace on the process and post the logs.

[toc] | [prev] | [next] | [standalone]

#1155368 — Bug#1041014: systemd-timesyncd: data collected by reportbug, new journal

[Multipart message — attachments visible in raw view] — view raw

Michael, thanks for taking a look. Last time I started /lib/systemd/systemd-timesyncd directly as root from the command line was several days ago, way before the today upload of the new versions of systemd and systemd-timesyncd to stable. Back then, /lib/systemd/systemd-timesyncd did start, did not print anything and also did not terminate by itself. Hitting Ctrl+C killed/terminated it, leading me back to the usual bash prompt. Is this the expected behavior? If this behavior is still the same after the today upgrade, should I still run strace on the process and post the logs or do something else? (I'm going to check in a few days because I don't always have the laptop on which the bug occurs at my disposal.)
(Wild guess: Presumably, during the upgrade from Debian 11 to Debian 12 some important packages that should be installed in their amd64 versions could have hypothetically been installed, for whatever reason, in i386. This is something I observed today on a different machine during an otherwise uneventful, routine upgrade of dbus. I can try to check via `sudo dpkg -l | awk '/^ii/ && $4 == "i386" { print }'`.)
Gratefully,
AlMa

[toc] | [prev] | [next] | [standalone]

#1156394 — Bug#1041014: Permission of /lib64 were wrong

[Multipart message — attachments visible in raw view] — view raw

In the meantime, I tried to see which file runs /lib/systemd/systemd-timesyncd:
# file /lib/systemd/systemd-timesyncd
… interpreter /lib64/ld-linux-x86-64.so.2 …
So I took a look at its directory:
# ls -la /lib64
… /lib64 -> usr/lib64
# ls -la /usr/lib64
drw------  3 root root 4096 22. Jul 17:23 .
…
I thought, someone else than root might try to execute whatever is inside there and went on with
# chmod +rx /usr/lib64
so that I got
drwr-xr-x  3 root root 4096 22. Jul 17:23 .
This solved the problem at least once:
# systemctl restart systemd-timesyncd
worked now:
# systemctl status systemd-timesyncd
…
Active: active (running) …
…
I'm absolutely sure I had NOT altered the permissions of /usr/lib64 or any other system directories myself before having issued the aforementioned chmod command today at all, so some part of or the system or of the upgrade from Debian 11 to Debian 12 must have set the directory persmissions to drw------ (presumably, for a good reason?). Are the new permissions drwr-xr-x fine?  If they are normal, is there anything else I need to do?  If they are too permissive, should I change them back and still run strace on /lib/systemd/systemd-timesyncd (and if not, what else to do)?
Gratefully,
Alma

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web