[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Libgksu & configuration support

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Libgksu & configuration support
Date: Wed, 19 Dec 2007 17:13:29 -0700
User-agent: KMail/1.9.7

On Wednesday 19 December 2007, Milan wrote:
> Christian Grothoff a écrit :
> > Ok, assuming that what you're trying to talk about is starting gnunetd
> > from gnunet-gtk and your issue is that the existing gnunet-util
> > "start-daemon" functions wouldn't work -- why not just avoid using them
> > entirely if you use libgdksu?  As for process priorities,pidfile, etc, I
> > don't think those are an issue since you can just read the values from
> > gnunetd.conf (if gtksu needs them) -- remember, you can load a 2nd
> > configuration file using the new GNUNET_GC_* apis (so you can have both a
> > gnunet.conf and a gnunetd.conf in memory at the same time and know which
> > one you're using when).
> OK that should work well.
> > So I think my answer is: you don't have to use the gnunet-util functions
> > to start/stop gnunetd if they are not appropriate.  Does that answer your
> > question(s)?
> So I can simply use my own methods with libgksu (by the way, note it's
> not called /libgdksu/ and has nothing to do with GDK/GTK ;-) ) imitating
> what launchWithExec does. But I can see that this function uses
> hardcoded nice values: maybe the best would be to get this from the
> config file so that it can be modified.

Yes, I agree that "nice(10)" is far from perfect.  Could be fixed, but I don't 
think this has anything to do with your issue at hand.  We can easily add an 
option "PRIORITY" (back) to gnunetd.conf.

> Maybe also using pid files like /var/run/gnunetd/ in Debian
> could be good to integrate better with the system (so that event-based
> services managers like upstart could still decide when to start/stop
> gnunetd, for example when network is up/down). Again, an entry in
> gnunetd.conf would do the trick and ensure we will never conflict with
> the distrib.

We already have that in the configuration file: "PIDFILE" is the option that 
you are looking for.

> This said, there shouldn't be any issue with that feature and I'll look
> into this.
> >> PS: would it make sense I ask Debian to set dependencies for gnunet-*
> >> packages so that the whole series (gnunet-server, gnunet-gtk,
> >> gnunet-qt...) require from each other the very same version (eg =
> >> 0.7.2c)? At the moment, you can use gnunet-gtk 0.7.1 with gnunetd
> >> 0.7.2c, which brought me a crash in Ubuntu.
> >
> > Well, having all of them require an exact match may not always be
> > correct. For example, we may not always have a new gnunet-qt/gtk/fuse
> > release when we change GNUnet, and these versions maybe compatible
> > (sometimes).
> >
> > Now, the 0.7.3 release should be flagged to conflict with any previous
> > release of any of the other packages.  And whenever we break
> > compatibility like this, a conflict should be put in.  But I don't think
> > we should by default always require exact matches (since this may
> > sometimes force unnecessary package updates).
> I open a bug about that and libgksu2 with this explanation. So for each
> release they should ask or look at a document where this is written.
> Another point: could you add on the website that libgksu2 is a
> recommended/facultative gnunet-gtk build requirement? libnotify could be
> there too.



> Good hacking towards 0.7.3!
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]