1

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.

Improve this question
3
  • Did you restart cron? I think you need to when you edit the various /etc/cron* entities.
    – Jason Tan
    Jun 18, 2009 at 6:05
  • Crontab hasn't changed, and run-parts /etc/cron.hourly will do the right thing.
    – Norman Ramsey
    Jun 19, 2009 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, 2009 at 17:25

4 Answers 4

Reset to default
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?

Improve this answer
1
  • 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, 2009 at 20:12
1

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

/etc/xdg/autostart/gdl_box.desktop

Improve this answer
3
  • 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, 2009 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, 2009 at 20:26
  • I'm in runlevel 2. I run startx which runs my ~/.Xsession which runs fvwm.
    – Norman Ramsey
    Jun 19, 2009 at 17: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.

Improve this answer
2
  • Yes, that's how I learned that init(8) is forking gdl_box directly.
    – Norman Ramsey
    Jun 17, 2009 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, 2009 at 11:17
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.

Improve this answer
1
  • No gdl's lurking there.
    – Norman Ramsey
    Jun 19, 2009 at 17:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .