summaryrefslogtreecommitdiff
path: root/netifd/patches/utils-fix-check_pid_path-to-work-with-delted-file-as.patch
diff options
context:
space:
mode:
authorKarel Kočí <cynerd@email.cz>2020-05-28 11:29:34 +0200
committerKarel Kočí <cynerd@email.cz>2020-05-28 11:29:34 +0200
commitc606e009f2639c6b0518c9ad2bdf2b77c35ca6e5 (patch)
tree23efbf3e0456a78bb4a820037789477b8ab8881d /netifd/patches/utils-fix-check_pid_path-to-work-with-delted-file-as.patch
parent68bf801ffbda2868703db98cfb2625232da9535c (diff)
downloadopenwrt-personal-pkgs-c606e009f2639c6b0518c9ad2bdf2b77c35ca6e5.tar.gz
openwrt-personal-pkgs-c606e009f2639c6b0518c9ad2bdf2b77c35ca6e5.tar.bz2
openwrt-personal-pkgs-c606e009f2639c6b0518c9ad2bdf2b77c35ca6e5.zip
Add netifd with patch to fix service restart
Diffstat (limited to 'netifd/patches/utils-fix-check_pid_path-to-work-with-delted-file-as.patch')
-rw-r--r--netifd/patches/utils-fix-check_pid_path-to-work-with-delted-file-as.patch69
1 files changed, 69 insertions, 0 deletions
diff --git a/netifd/patches/utils-fix-check_pid_path-to-work-with-delted-file-as.patch b/netifd/patches/utils-fix-check_pid_path-to-work-with-delted-file-as.patch
new file mode 100644
index 0000000..82a6441
--- /dev/null
+++ b/netifd/patches/utils-fix-check_pid_path-to-work-with-delted-file-as.patch
@@ -0,0 +1,69 @@
+From 8ce3d13d9ba56543c2d627fd429fab171b40994e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Karel=20Ko=C4=8D=C3=AD?= <cynerd@email.cz>
+Date: Thu, 28 May 2020 10:43:44 +0200
+Subject: [PATCH] utils: fix check_pid_path to work with delted file as well
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+check_pid_patch is checking if process with given PID and executable
+path is running. If this code fails the rest of the code can be
+convinced that program is no longer running and possibly spawns new
+instance that can collide with already running one. This behavior was
+reproduced with hostapd.
+
+Symbolic link exe in process subdirectory in /proc points to original
+executable. The problem is that it reads as original path plus string
+' (deleted)' if file is removed. The process is still running but
+original file is no longer available on files ystem.
+
+This behavior is triggered not only when file is removed (unlinked) but
+also when file is replaced. This happens clearly on package update. In
+general this happens any time all references (hard links) to file are
+removed from file system.
+
+This is not ultimate fix as exe link points to any last reference on
+file system with preference for original one. The problem is if there
+are multiple references and the original one is removed. This can be
+reproduced just by copying executable (hard linking) and unlinking the
+original one. In such case exe link would point to copy and not to
+original deleted one.
+
+Signed-off-by: Karel Kočí <cynerd@email.cz>
+---
+ utils.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/utils.c b/utils.c
+index ba26952..4f40b4b 100644
+--- a/utils.c
++++ b/utils.c
+@@ -176,6 +176,8 @@ crc32_file(FILE *fp)
+
+ bool check_pid_path(int pid, const char *exe)
+ {
++ const char deleted[] = " (deleted)";
++ const int deleted_len = strlen(deleted);
+ int proc_exe_len;
+ int exe_len = strlen(exe);
+
+@@ -191,10 +193,13 @@ bool check_pid_path(int pid, const char *exe)
+ proc_exe_len = readlink(proc_exe, proc_exe_buf, exe_len);
+ #endif
+
+- if (proc_exe_len != exe_len)
++ if (proc_exe_len == exe_len)
++ return !memcmp(exe, proc_exe_buf, exe_len);
++ else if (proc_exe_len == exe_len + deleted_len)
++ return !memcmp(exe, proc_exe_buf, exe_len) &&
++ !memcmp(exe + exe_len, deleted, deleted_len);
++ else
+ return false;
+-
+- return !memcmp(exe, proc_exe_buf, exe_len);
+ }
+
+ static const char * const uci_validate_name[__BLOBMSG_TYPE_LAST] = {
+--
+2.26.2
+