Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 57110 - xfs init script leaves daemon's cwd set to the last fontpath element
xfs init script leaves daemon's cwd set to the last fontpath element
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-12-04 18:40 EST by edwinh
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-02-05 23:59:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description edwinh 2001-12-04 18:40:49 EST
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:

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 01:42:25 EST
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 01:43:15 EST
Created attachment 43435 [details]
xfs initscript
Comment 3 edwinh 2002-01-25 18:03:33 EST
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 08:21:48 EST
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 02:57:53 EST
My patch is now in rawhide XFree

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