Ich habe daemontools-0.76 gemäß den offiziellen Dokumenten hier auf einem CentOS 8-System installiert:http://cr.yp.to/daemontools.html.
Ich habe dann einen Testdienst erstellt, der /service/test
mit einer einfachen run
Datei verknüpft ist, die Text an stdout zurückgibt (so einfach wie es nur geht). Sowohl der Testordner als auch die Run-Datei haben 755 Berechtigungen.
run
Datei:
#!/bin/sh
echo "test"
Die Datei lässt sich natürlich auch manuell ausführen und /command/supervise /service/test
der Dienst läuft wie erwartet. Ich kann ihn svc -u/-d <service>
über den Supervisor starten/stoppen.
Beim Ausführen /command/svscan /service
erhalte ich jedoch die folgende Fehlermeldung:
svscan: warning: unable to start supervise test: permission denied
Ich habe keine Hinweise darauf gefunden, welche Berechtigungen hier in Konflikt stehen. Dinge, die ich versucht habe:
- Sowohl mit dem
test/supervise
vorhandenen Ordner (erstellt beimsupervise
manuellen Ausführen) als auch mit diesem entfernten Ordner (d. h. beim Neustarten des Dienstes); das Ergebnis ist in beiden Fällen dasselbe (Hinweis:supervise
läuft nicht, wenn ich versuche, ihn zu startensvscan
, obwohl ich es auch mit im Hintergrund laufendem Dienst versucht habe, mit demselben Fehler) - Überprüfte Berechtigungen (755) für die Befehle selbst (unter
/package/admin/daemontools-0.76/command/
) - Überprüfte Berechtigungen (755) für alle Ordner (/command, /service, /package und den Serviceordner)
- Ich dachte, dass es vielleicht ein Problem sein könnte, wenn irgendetwas versucht, dieses Verzeichnis zu verwenden, da
/tmp
es gemountet ist , aber ich habe es erneut versucht, obwohl es gemountet war , und das hat nicht geholfennoexec
exec
- Ich dachte, ein
strace
könnte helfen, aber für mein ungeübtes Auge scheint es keine Probleme zu geben:
execve("/usr/local/bin/svscan", ["svscan", "/service"], 0x7ffc7385cfe8 /* 21 vars */) = 0
brk(NULL) = 0x1eab000
arch_prctl(0x3001 /* ARCH_??? */, 0x7fff479dd530) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=34379, ...}) = 0
mmap(NULL, 34379, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7af1b35000
close(3) = 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2607\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=4176104, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7af1b33000
mmap(NULL, 3938144, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7af1554000
mprotect(0x7f7af170d000, 2093056, PROT_NONE) = 0
mmap(0x7f7af190c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b8000) = 0x7f7af190c000 mmap(0x7f7af1912000, 14176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7af1912000
close(3) = 0
arch_prctl(ARCH_SET_FS, 0x7f7af1b34500) = 0
mprotect(0x7f7af190c000, 16384, PROT_READ) = 0
mprotect(0x603000, 4096, PROT_READ) = 0
mprotect(0x7f7af1b3e000, 4096, PROT_READ) = 0
munmap(0x7f7af1b35000, 34379) = 0
chdir("/service") = 0
wait4(-1, 0x7fff479dd4fc, WNOHANG, NULL) = -1 ECHILD (No child processes)
openat(AT_FDCWD, ".", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
brk(NULL) = 0x1eab000
brk(0x1ecc000) = 0x1ecc000
brk(NULL) = 0x1ecc000
getdents64(3, /* 3 entries */, 32768) = 72
stat("test", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("test/log", 0x7fff479dd430) = -1 ENOENT (No such file or directory)
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f7af1b347d0) = 2884
getdents64(3, /* 0 entries */, 32768) = 0
close(3) = 0
nanosleep({tv_sec=5, tv_nsec=0}, svscan: warning: unable to start supervise test: permission denied
Irgendwelche Gedanken?
Bearbeiten: Ich habe gerade genau dieselben Schritte auf einer CentOS 7-Maschine ausprobiert und es funktioniert einwandfrei. Vielleicht liegt es an einem Problem mit Glibc-Aufrufen in der Codebasis, die nicht mit späteren Versionen (2.17 vs. 2.28) kompatibel ist?