After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 211984 - alarm daemon should exit if there are no future alarms
alarm daemon should exit if there are no future alarms
Status: RESOLVED DUPLICATE of bug 225828
Product: evolution
Classification: Applications
Component: Calendar
pre-1.5 (obsolete)
Other All
: Normal enhancement
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
: 213121 214001 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-10-07 22:30 UTC by Dan Winship
Modified: 2013-09-10 14:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Dan Winship 2001-10-07 22:30:43 UTC 






Comment 1


Federico Mena Quintero





          2001-10-26 07:40:59 UTC
        



But what happens if another client (a conduit, or whatever) adds a
future appointment with an alarm?  The Wombat cannot launch the alarm
daemon.  Hmm, maybe it should.






Comment 2


Federico Mena Quintero





          2001-10-29 19:24:23 UTC
        



*** bug 213121 has been marked as a duplicate of this bug. ***






Comment 3


Federico Mena Quintero





          2001-11-01 00:23:32 UTC
        



Assigning to myself.  Will change the alarm daemon to exit if there
are no future alarms, and the Wombat to launch the daemon if an event
gets added and it has an alarm in the future.






Comment 4


Federico Mena Quintero





          2001-11-01 19:09:15 UTC
        



*** bug 214001 has been marked as a duplicate of this bug. ***






Comment 5


Ettore Perazzoli





          2002-07-25 18:24:26 UTC
        



It would be nice to have this fixed in 1.2, since people who put
Evolution on centralized servers with lots of users (eg. with Sunrays)
complain about the stray processes.






Comment 6


Gerardo Marin





          2002-11-30 06:03:51 UTC
        



Moving milestone to future, since 1.2 is gone and 1.4 is porting.






Comment 7


Chakravarthi





          2005-11-07 06:01:23 UTC
        



After discussion with calendar maintainers the following points are 
thought of as possible conclusions to this problem.
1) As e-a-n is another client to e-d-s (like evolution is) it doesnot 
   make too much sense to remove it when evolution exits.
2) As the memory used by e-a-n is that of the appointments of current day
   alone, adding additional code to close it when there are no future 
   alarms doesn't save anything,
2) However, as it is a separate process, an UI change in alarm notification
   needs to be done to show its independence. Please have a look a patch 
   that provides exactly this at the following link.

http://mail.gnome.org/archives/evolution-patches/2005-November/msg00001.html






Comment 8


Chakravarthi





          2005-11-07 06:33:11 UTC
        



Marking this as duplicate of 

*** This bug has been marked as a duplicate of 225828 ***