Re: bug in NSApplication

[Chris B . Vetter]

On Tue, 16 Jul 2002 15:35:09 +0100 (BST)
Nicola Pero <address@hidden> wrote:
> > However, upon launching gdomap and gdnc, the former complained that
> > it wasn't able to connect to port 538. Closer inspection showed that
> > the creation of /var/run/gdomap.pid happens _after_ switching to user
> > 'nobody' - bad idea, since (at least) on BSD systems, /var/run is only
> > writable by root. Ok, that's easy enough to fix, I can either move the
> > creation before the user switch, or chmod /var/run. Though I prefer to
> > do the former.
> If I understand correctly, your problem is that you are running gdomap as
> root (at startup), so you're not really using the setuid 'feature', and
> you would like it to write out its pid to a root only file, and you are
> complaining that it no longer can write to the file even if you run it as
> root.

I was merely stating the fact, that since I updated to a newer version of
GNUstep, gdomap refuses to run - though I haven't changed any of my startup
scripts. If you (in general) do not know what to look for, the 'error'
message you will get in this case, isn't really helpful, as it states that
/etc/services doesn't have an entry for gdomap. Well, that's WAY off...

GNUstep-HOWTO states, that gdomap is supposed to run off a system startup
script, like /etc/rc.local - which means in this case it _will_ be launched
under user 'root'.
Yes, I do know I can specify -I </path/to/pidfile> which usually points to
/var/run/<pidfile> - however, on BSD-style UNICES, like SunOS/Solaris and
the various *BSDs, /var/run is only writeable by root. Therefor, the way
gdomap works right now, it cannot start, since it cannot create its pidfile
(unless -I specifies a different path, say /tmp/gdomap.pid)

So, gdomap _should_ then complain that it cannot create its pidfile, instead
of complaining about a missing entry in /etc/services.

That's all I was pointing out.

-- 
Chris