Wie kann ich ein Init-Skript eines Ubuntu-Systems richtig aktualisieren?
Ich versuche, meine Gitlab-Version von 6-0 auf 6-1 zu aktualisieren. Ein Teil der Aktualisierung besteht aus dem Ersetzen des Init-Skripts.
sudo rm /etc/init.d/gitlab
sudo curl --output /etc/init.d/gitlab https://raw.github.com/gitlabhq/gitlabhq/6-1-stable/lib/support/init.d/gitlab
sudo chmod +x /etc/init.d/gitlab
Ich stelle fest, dass nach dem Aktualisieren des Init-Skripts der Aufruf des Skripts nichts bewirkt. Normalerweise gibt es die Prozess-ID des Gitlab-Dienstes aus
root@gitlab:/etc/init.d# /etc/init.d/gitlab status
root@gitlab:/etc/init.d# (notice how nothing happens)
#No gitlab process is running
root@gitlab:/etc/init.d# ps aux |grep gitlab
root 4519 0.0 0.1 9384 928 pts/0 R+ 20:03 0:00 grep --color=auto gitlab
Schritte, die ich zur Fehlerbehebung unternommen habe:
Stellen Sie sicher, dass es ausführbar ist
root@gitlab:/etc/init.d# ll gitlab
-rwxr-xr-x 1 root root 7195 Sep 28 19:29 gitlab*
Strace das Skript
root@gitlab:/etc/init.d# strace ./gitlab
execve("./gitlab", ["./gitlab"], [/* 16 vars */]) = 0
brk(0) = 0xb29000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd33a1a8000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=22291, ...}) = 0
mmap(NULL, 22291, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fd33a1a2000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\30\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1811128, ...}) = 0
mmap(NULL, 3925208, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fd339bc9000
mprotect(0x7fd339d7e000, 2093056, PROT_NONE) = 0
mmap(0x7fd339f7d000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b4000) = 0x7fd339f7d000
mmap(0x7fd339f83000, 17624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fd339f83000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd33a1a1000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd33a1a0000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd33a19f000
arch_prctl(ARCH_SET_FS, 0x7fd33a1a0700) = 0
mprotect(0x7fd339f7d000, 16384, PROT_READ) = 0
mprotect(0x619000, 4096, PROT_READ) = 0
mprotect(0x7fd33a1aa000, 4096, PROT_READ) = 0
munmap(0x7fd33a1a2000, 22291) = 0
getpid() = 4459
rt_sigaction(SIGCHLD, {0x40f100, ~[RTMIN RT_1], SA_RESTORER, 0x7fd339bff4a0}, NULL, 8) = 0
geteuid() = 0
brk(0) = 0xb29000
brk(0xb4a000) = 0xb4a000
getppid() = 4458
stat("/etc/init.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("./gitlab", O_RDONLY) = 3
fcntl(3, F_DUPFD, 10) = 10
close(3) = 0
fcntl(10, F_SETFD, FD_CLOEXEC) = 0
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x40f100, ~[RTMIN RT_1], SA_RESTORER, 0x7fd339bff4a0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7fd339bff4a0}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7fd339bff4a0}, NULL, 8) = 0
read(10, "#! /bin/sh\n\n# GITLAB\n# Maintaine"..., 8192) = 7195
stat("/usr/local/sbin/sudo", 0x7fffcbf518d0) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/sudo", 0x7fffcbf518d0) = -1 ENOENT (No such file or directory)
stat("/usr/sbin/sudo", 0x7fffcbf518d0) = -1 ENOENT (No such file or directory)
stat("/usr/bin/sudo", {st_mode=S_IFREG|S_ISUID|0755, st_size=71288, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fd33a1a09d0) = 4460
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 4460
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigreturn(0x11) = 4460
exit_group(1) = ?
Ich bin mit Cent besser vertraut als mit Ubuntu und höre unterschiedliche Meinungen zum manuellen Ausführen von update-rc.d. Ich habe es trotzdem gemäß demVorschlag dieses Blogs
root@gitlab:/etc/init.d# sudo update-rc.d -f gitlab remove
Removing any system startup links for /etc/init.d/gitlab ...
/etc/rc0.d/K20gitlab
/etc/rc1.d/K20gitlab
/etc/rc2.d/S20gitlab
/etc/rc3.d/S20gitlab
/etc/rc4.d/S20gitlab
/etc/rc5.d/S20gitlab
/etc/rc6.d/K20gitlab
root@gitlab:/etc/init.d# update-rc.d gitlab defaults
Adding system startup for /etc/init.d/gitlab ...
/etc/rc0.d/K20gitlab -> ../init.d/gitlab
/etc/rc1.d/K20gitlab -> ../init.d/gitlab
/etc/rc6.d/K20gitlab -> ../init.d/gitlab
/etc/rc2.d/S20gitlab -> ../init.d/gitlab
/etc/rc3.d/S20gitlab -> ../init.d/gitlab
/etc/rc4.d/S20gitlab -> ../init.d/gitlab
/etc/rc5.d/S20gitlab -> ../init.d/gitlab
Kein Glück, das Skript läuft immer noch nicht.
Muss auf Ubuntu-Systemen noch etwas anderes getan werden, um Init-Skripte zu aktualisieren?
Update 1:
Ein Blick auf /var/log/auth.log zeigt:
vagrant@gitlab:~$ sudo su -
root@gitlab:~# /etc/init.d/gitlab status
root@gitlab:~# tail /var/log/auth.log
Sep 28 20:52:31 gitlab su[2205]: pam_unix(su:session): session closed for user root
Sep 28 20:52:31 gitlab sudo: pam_unix(sudo:session): session closed for user root
Sep 28 20:52:34 gitlab sudo: vagrant : TTY=pts/0 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/su -
Sep 28 20:52:34 gitlab sudo: pam_unix(sudo:session): session opened for user root by vagrant(uid=1000)
Sep 28 20:52:34 gitlab su[2311]: Successful su for root by root
Sep 28 20:52:34 gitlab su[2311]: + /dev/pts/0 root:root
Sep 28 20:52:34 gitlab su[2311]: pam_unix(su:session): session opened for user root by vagrant(uid=0)
Sep 28 20:52:43 gitlab sudo: root : TTY=pts/0 ; PWD=/root ; USER=git ; COMMAND=/bin/false -c /etc/init.d/gitlab status
Sep 28 20:52:43 gitlab sudo: pam_unix(sudo:session): session opened for user git by vagrant(uid=0)
Sep 28 20:52:43 gitlab sudo: pam_unix(sudo:session): session closed for user git
Update 2:
Ich habe einen Diff der Init-Skripte zwischen 6-0-stable und 6-1-stable durchgeführt. Es scheint sich um eine fast vollständige Neufassung gehandelt zu haben.
Der Diff befindet sich hier:
https://gist.github.com/spudstud/6747146#file-diff-gitlab-init-scripts
Das eigentliche 6-0-Skript können Sie hier sehen:
https://github.com/gitlabhq/gitlabhq/blob/6-0-stable/lib/support/init.d/gitlab
und das 6-1-Skript hier:
https://github.com/gitlabhq/gitlabhq/blob/6-1-stable/lib/support/init.d/gitlab
Update 3:
Habe versucht, das Skript mit bash -x zu starten
root@gitlab:/etc/init.d# bash -x /etc/init.d/gitlab start
+ RAILS_ENV=production
+ app_root=/home/git/gitlab
+ app_user=git
+ unicorn_conf=/home/git/gitlab/config/unicorn.rb
+ pid_path=/home/git/gitlab/tmp/pids
+ socket_path=/home/git/gitlab/tmp/sockets
+ web_server_pid_path=/home/git/gitlab/tmp/pids/unicorn.pid
+ sidekiq_pid_path=/home/git/gitlab/tmp/pids/sidekiq.pid
+ '[' root '!=' git ']'
+ sudo -u git -H -i /etc/init.d/gitlab start
+ exit
Erfolg,
Es scheint, dass das Skript als Benutzer „git“ ausgeführt werden muss.
Antwort1
Um Bash- oder Shell-Skripte zu debuggen, ist es hilfreich, sie entweder mit auszuführen bash -xoder das Skript zu bearbeiten und eine Zeile mit dem Inhalt hinzuzufügen set -x. Dadurch wird die Ausführungsverfolgung jeder Zeile im Skript während der Ausführung zusammen mit dem Wert der Variablenzuweisungen angezeigt.
Antwort2
Ich habe die Lösung für das Problem gefunden, für die keine Änderung des Init-Skripts erforderlich ist.
Die Anweisungen für Gitlab weisen den Benutzer an, zu verwenden adduser --disabled-login. Anstatt zu verwenden, adduserhabe ich Puppet verwendet, um den Benutzer hinzuzufügen und die Standard-Shell auf /bin/false statt /bin/bash einzustellen.
Sobald ich die Shell meines „Git“-Benutzers auf /bin/bash geändert hatte, funktionierte das Init-Skript wieder ordnungsgemäß.