Project

General

Profile

Bug #654

multiple greyhole processes

Added by cpg over 10 years ago. Updated over 10 years ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
10/21/2010
Due date:
% Done:

0%


Description

not sure why this is - but it seems bad. GH is not enabled. how can this be fixed?

running hda-greyhole-0.6.26-1.x86_64

$ get greyhole
root      1072  0.0  0.1 214364 14168 ?        S    Oct18   0:00 /usr/bin/php /usr/bin/greyhole --prerotate
root      4005  0.0  0.1 214368 12620 ?        SN   Oct15   0:00 /usr/bin/php /usr/bin/greyhole --prerotate
root      5936  0.0  0.1 214364 14172 ?        S    Oct20   0:00 /usr/bin/php /usr/bin/greyhole --prerotate
root     11573  0.0  0.0   9184  1084 ?        Ss   Oct17   0:00 /bin/sh -c /usr/bin/greyhole --fsck --email-report > /dev/null
root     11576  0.0  0.1 214364 14152 ?        S    Oct17   0:00 /usr/bin/php /usr/bin/greyhole --fsck --email-report
root     12439  0.0  0.0   9184  1088 ?        Ss   Oct19   0:00 /bin/sh -c /usr/bin/greyhole --fsck --email-report > /dev/null
root     12442  0.0  0.1 214364 14168 ?        S    Oct19   0:00 /usr/bin/php /usr/bin/greyhole --fsck --email-report
root     15322  0.0  0.1 311240 14260 ?        SN   Oct20   0:00 /usr/bin/php /usr/bin/greyhole --daemon
root     15350  0.0  0.0   9184  1084 ?        Ss   00:00   0:00 /bin/sh -c /usr/bin/greyhole --fsck --email-report > /dev/null
root     15355  0.0  0.1 214364 14184 ?        S    00:00   0:00 /usr/bin/php /usr/bin/greyhole --fsck --email-report
root     16504  0.0  0.1 214364 14168 ?        S    Oct17   0:00 /usr/bin/php /usr/bin/greyhole --prerotate
root     17314  0.0  0.1 214364 14168 ?        S    Oct19   0:00 /usr/bin/php /usr/bin/greyhole --prerotate
root     26774  0.0  0.0   9184  1080 ?        Ss   Oct16   0:00 /bin/sh -c /usr/bin/greyhole --fsck --email-report > /dev/null
root     26779  0.0  0.1 214364 14148 ?        S    Oct16   0:00 /usr/bin/php /usr/bin/greyhole --fsck --email-report
root     28244  0.0  0.0   9184  1080 ?        Ss   Oct20   0:00 /bin/sh -c /usr/bin/greyhole --fsck --email-report > /dev/null
root     28248  0.0  0.1 214364 14172 ?        S    Oct20   0:00 /usr/bin/php /usr/bin/greyhole --fsck --email-report
root     28923  0.0  0.0   9184  1088 ?        Ss   Oct18   0:00 /bin/sh -c /usr/bin/greyhole --fsck --email-report > /dev/null
root     28924  0.0  0.1 214364 14164 ?        S    Oct18   0:00 /usr/bin/php /usr/bin/greyhole --fsck --email-report
root     30948  0.0  0.1 214364 14152 ?        S    Oct16   0:00 /usr/bin/php /usr/bin/greyhole --prerotate

History

#1 Updated by gboudreau over 10 years ago

  • Assignee changed from gboudreau to cpg

To fix this: I'd need to understand why they are still running.
An strace of a process that does --prerotate, and one that does --fsck, might help. The most recent ones maybe.
If strace don't show anything, maybe try to launch the command yourself using strace, and see where it stops.

#2 Updated by cpg over 10 years ago

they both seem to be in the same place

for the prerotate ones:

[03:57:46](1)milan:~$ sudo strace -p 1072
Process 1072 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>^C <unfinished ...>
Process 1072 detached
[03:57:50](1)milan:~$ sudo strace -p 30948
Process 30948 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>^C <unfinished ...>
Process 30948 detached
[03:58:01](1)milan:~$ 

for fsck:

[03:58:33](1)milan:~$ sudo strace -p 28924
Process 28924 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>^C <unfinished ...>
Process 28924 detached
[03:58:41](1)milan:~$ sudo strace -p 28248
Process 28248 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>^C <unfinished ...>
Process 28248 detached
[03:59:31](1)milan:~$

running by hand with strace:

read(3, "root, \"$path/$filename\", $share)"..., 8192) = 8192
read(3, "y]);\n\t\t\t\tunset($file_tombstones["..., 8192) = 8192
read(3, "ach ($file_tombstones as $key =>"..., 8192) = 8192
read(3, "_query(\"REPAIR TABLE settings\") "..., 8192) = 8192
read(3, "ileperms' => (int) base_convert("..., 8192) = 8192
read(3, ", share, full_path, additional_i"..., 8192) = 4947
read(3, "", 8192)                       = 0
read(3, "", 8192)                       = 0
close(3)                                = 0
brk(0x1454000)                          = 0x1454000
brk(0x1494000)                          = 0x1494000
write(2, "Oct 21 04:00:13 4 initialize: Yo"..., 94Oct 21 04:00:13 4 initialize: You have no storage_pool_directory defined. Greyhole can't run.
) = 94
access("/usr/bin/hdactl", F_OK)         = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({600, 0}, ^C <unfinished ...>
[04:00:17](1)milan:~$ 

#3 Updated by cpg over 10 years ago

huh??

access("/usr/bin/hdactl", F_OK)         = 0

#4 Updated by gboudreau over 10 years ago

  • Assignee changed from cpg to gboudreau

This is the infinite loop that was added for amahi (thus the check for the existence of the /usr/bin/hdactl file, to identify Amahi).
I guess this loop shouldn't apply to anything else than the daemon, but since the loop is entered when the config parsing fails, it's entered before the parameters are even parsed, thus why it enter an infinite loop now for --fsck and --prerotate too.

#5 Updated by gboudreau over 10 years ago

  • Assignee changed from gboudreau to cpg

See if 0.6.28 (you should receive a notif. email soon) fixes this.

Also available in: Atom