How can I find out what is causing init(8) to launch a process?

Question

I installed Google Desktop for Linux and want to prevent it from running without necessarily deleting all its files. I managed to find and disable the file in /etc/cron.hourly, but gdl_box is still being launched by process 1:

1  5199  5199  5199 ?           -1 Ss   32074   0:01 /opt/google/desktop/bin/gdl_box

I've grepped for gdl in every file under /etc and have turned up no suspects. There doesn't seem to be anything in /etc/init.d or in the /etc/rc*.d directories. How can I find and slay this evil daemon? More exactly, how can I find out what is causing it to be spawned and prevent it from ever spawning in the first place?

I have killed the gdl_box over and over, but without a reboot or an X restart, something in the system keeps respawning it. I would like to find out what and stop it.

EDIT

OK, eventually I replaced gdl_box with a binary that ran ps afwj so I could tell who launched it before it got adopted by init. Imagine my embarrassment when I discovered it was launched from my .profile. I still would love to know a better way to have discovered this, but I've accepted the answer which pointed out the adoption by init (thanks Thomas) which at least stopped me looking under the wrong lamppost.

Did you restart cron? I *think* you need to when you edit the various /etc/cron* entities. — Jason Tan, Jun 18 '09 at 06:05
Crontab hasn't changed, and run-parts /etc/cron.hourly will do the right thing. — Norman Ramsey, Jun 19 '09 at 17:17
I haven't found anything useful in the logs. (Plenty of sudo with me killing processes, and the occasional segfault from gdl_indexer.) — Norman Ramsey, Jun 19 '09 at 17:25

score 2 · Accepted Answer · answered Jun 17 '09 at 18:07

2

I assume the first column in the ps output you show is the parent pid (PPID). If so, it's probably not spawned by init (if that is what led you to believe that), but in normal unix daemon-style it double-forks which causes it to get a parent pid of 1. It was a orphan and init adopted it.

How can you find and slay it? Uh... it's right there, what aren't you finding?

answered Jun 17 '09 at 18:07

Thomas

1,446
11
16

Sorry -- I've edited question to show I want to know how to prevent the daemon from spawning. Killing it does no good is something else keeps spawning it. – Norman Ramsey Jun 17 '09 at 20:12

score 1 · Answer 2 · answered Jun 17 '09 at 19:23

1

Google desktop is started from (at least on my RHEL5 system):

/etc/xdg/autostart/gdl_box.desktop

answered Jun 17 '09 at 19:23

TCampbell

2,014
14
14

I'm not running xdm or gdm, and neither gnome-at-visual or gnome-volume-manager are running (which are also in that directory). – Norman Ramsey Jun 17 '09 at 20:10
Are you in run-level 5? Are you starting any type of X11 environment (if not from xdm or gdm)? – TCampbell Jun 17 '09 at 20:26
I'm in runlevel 2. I run startx which runs my ~/.Xsession which runs fvwm. – Norman Ramsey Jun 19 '09 at 17:19

score 0 · Answer 3 · answered Jun 17 '09 at 18:19

0

Some versions of ps support a --forest or f flag to show the tree of relationships between processes. If your version doesn't have that, check for pstree, a stand-alone package to do the same thing. It can help in cases like this.

answered Jun 17 '09 at 18:19

Telemachus

561
2
11

Yes, that's how I learned that init(8) is forking gdl_box directly. – Norman Ramsey Jun 17 '09 at 20:07
init is not forking gdl_box directly. I can pretty much guarantee that. See my answer about double-fork. – Thomas Jun 18 '09 at 11:17

score 0 · Answer 4 · answered Jun 18 '09 at 02:26

0

What about running

find /var/spool/cron -type f | xargs grep gdl

or maybe there is a script that is loading gdl_box, but the script is not actually called gdl itself which is why a grep isn't turning anything up.

answered Jun 18 '09 at 02:26

resonator

281
1
10

No gdl's lurking there. – Norman Ramsey Jun 19 '09 at 17:20

How can I find out what is causing init(8) to launch a process?

EDIT

4 Answers4