Bug 57110 - xfs init script leaves daemon's cwd set to the last fontpath element
Summary: xfs init script leaves daemon's cwd set to the last fontpath element
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-12-04 23:40 UTC by edwinh
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-02-06 04:59:17 UTC
Embargoed:


Attachments (Terms of Use)
xfs initscript (2.57 KB, text/plain)
2002-01-25 06:43 UTC, Mike A. Harris
no flags Details

Description edwinh 2001-12-04 23:40:49 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120

Description of problem:
xfs runs with its cwd set to the last fontpath element from /etc/X11/fs/config.

This is bad if you have a remote filesystem with fonts on it - you can
never umount the fs if xfs is running.  If it's automounted it will never
umount automatically.

The init script bit that iterates over the font paths is the culprit.

Changing the script so xfs's cwd is / should be easy.



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. run xfs
2. look at /proc/<xfs pid>/cwd - it's set to the last font element


	

Expected Results:  xfs's cwd should be /.

(or something less likely to be on a remote fs at least.)



Additional info:

Comment 1 Mike A. Harris 2002-01-25 06:42:25 UTC
This sounds reasonable to me.  I've fixed the init script, and am
attaching a copy here for you to try.  Please update the report
and let me know if this fixes the problem for you.

Comment 2 Mike A. Harris 2002-01-25 06:43:15 UTC
Created attachment 43435 [details]
xfs initscript

Comment 3 edwinh 2002-01-25 23:03:33 UTC
Well...not quite right I think.  I'd have just put "cd /", as the pushd/popd
will leave the cwd to be whatever dir you were in when the service is started.
There is no need to preserve where we were.

For example if you had a cd mounted, were in that dir when you restarted 
xfs for some _stupid_ reason [or not so stupid, I copied some .ttf files off 
the cd maybe and don't know about xfs restart :) ].  Later on I wanted to 
umount the CD -- mountpoint is busy.

I just did this with an automounted cdrom:

(58)ehuff-linux[~] cd /misc/cdrom

(60)ehuff-linux[/misc/cdrom] sudo service xfs stop 
Shutting down xfs:                                         [  OK  ]

(61)ehuff-linux[/misc/cdrom] sudo service xfs start
Starting xfs:                                              [  OK  ]

(62)ehuff-linux[/misc/cdrom] cd

(63)ehuff-linux[~] sudo umount /misc/cdrom
umount: /misc/cdrom: device is busy


daemons should have a cwd of / in general, or some dir where they own 
everything (maybe /etc/X11/fs for this case if anything).  This is really
something xfs should do after it forks, right after closing stdout and stdin
like a good daemon should...

Comment 4 Mike A. Harris 2002-01-28 13:21:48 UTC
I've created a patch for xfs which chdir()'s before fork(), and submitted
it to XFree86.org for inclusion in upstream CVS.

Comment 5 Mike A. Harris 2002-02-06 07:57:53 UTC
My patch is now in rawhide XFree


Note You need to log in before you can comment on or make changes to this bug.