Re: [Shr-User] [SHR-T] ffalarms
Jeffrey Ratcliffe writes: > 2010/9/20 Łukasz Pankowski : >>> Are you saying that if I want to schedule new alarms, at say, 6.00, >>> 6.05, and 6.10, then I should create 6.00, quit and restart ffalarms, >>> create 6.05, etc..? >> >> No, only if you set two alarms at 6.00 they both start at 6.00 and my >> schedule the next alarms two times. > > I've never done that. I do edit the alarms quite a bit, though - > mostly just changing the day. > > Whatever caused it, I am now seeing about 30 duplicates. To fix > things, should I just delete the duplicate scripts in /var/spool/at? > or is there a better way? Fixed in ffalarms git repository, should be soon in SHR-U, do not know when it hits SHR-T. Regards, Łukasz > > Regards > > Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] [SHR-T] ffalarms
Jeffrey Ratcliffe writes: > 2010/9/20 Łukasz Pankowski : >>> Are you saying that if I want to schedule new alarms, at say, 6.00, >>> 6.05, and 6.10, then I should create 6.00, quit and restart ffalarms, >>> create 6.05, etc..? >> >> No, only if you set two alarms at 6.00 they both start at 6.00 and my >> schedule the next alarms two times. > > I've never done that. I do edit the alarms quite a bit, though - > mostly just changing the day. It could also happen if you have a phone turned off for some time and there are at least two past alarms which will be started simultaneously by atd during system startup and each of them will schedule future alarms in the race. I should fix this issue when I find some time for it, but I cannot promise when it will happen. > > Whatever caused it, I am now seeing about 30 duplicates. To fix > things, should I just delete the duplicate scripts in /var/spool/at? > or is there a better way? Yes, you can delete all /var/spool/at/*ffa* files and then start ffalarms GUI or set new alarm in command line (for example: ffalarms -s now) and they will be rescheduled (you can check it with ffalarms -l). > > Regards > > Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] [SHR-T] ffalarms
2010/9/20 Łukasz Pankowski : >> Are you saying that if I want to schedule new alarms, at say, 6.00, >> 6.05, and 6.10, then I should create 6.00, quit and restart ffalarms, >> create 6.05, etc..? > > No, only if you set two alarms at 6.00 they both start at 6.00 and my > schedule the next alarms two times. I've never done that. I do edit the alarms quite a bit, though - mostly just changing the day. Whatever caused it, I am now seeing about 30 duplicates. To fix things, should I just delete the duplicate scripts in /var/spool/at? or is there a better way? Regards Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] [SHR-T] ffalarms
Jeffrey Ratcliffe writes: > Hi Łukasz, > > 2010/9/20 Łukasz Pankowski : >> I, as the author of ffalarms see it too :), but as no one complains I >> can live with it. The problem is that at the moment if you set multiple > > Well, it *is* rather annoying. > >> alarms at the same time they all schedule new alarms and due to race >> condition between them you end up with single alarm scheduled multiple >> times. The simultaneous alarm processes try to own a dbus name, so only > > Are you saying that if I want to schedule new alarms, at say, 6.00, > 6.05, and 6.10, then I should create 6.00, quit and restart ffalarms, > create 6.05, etc..? No, only if you set two alarms at 6.00 they both start at 6.00 and my schedule the next alarms two times. > >> List of alarms: >> >> ffalarms -l >> >> (see http://ffalarms.projects.openmoko.org/#command-line-options) >> >> or simply >> >> ls /var/spoolt/at > > Right. That shows lots of duplicates scheduled, although the 3 alarms > I would like are correctly defined. To fix things, should I just > delete the duplicate scripts in /var/spool/at? or is there a better > way? > > Regards > > Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] [SHR-T] ffalarms
Hi Łukasz, 2010/9/20 Łukasz Pankowski : > I, as the author of ffalarms see it too :), but as no one complains I > can live with it. The problem is that at the moment if you set multiple Well, it *is* rather annoying. > alarms at the same time they all schedule new alarms and due to race > condition between them you end up with single alarm scheduled multiple > times. The simultaneous alarm processes try to own a dbus name, so only Are you saying that if I want to schedule new alarms, at say, 6.00, 6.05, and 6.10, then I should create 6.00, quit and restart ffalarms, create 6.05, etc..? > List of alarms: > > ffalarms -l > > (see http://ffalarms.projects.openmoko.org/#command-line-options) > > or simply > > ls /var/spoolt/at Right. That shows lots of duplicates scheduled, although the 3 alarms I would like are correctly defined. To fix things, should I just delete the duplicate scripts in /var/spool/at? or is there a better way? Regards Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] [SHR-T] ffalarms
Jeffrey Ratcliffe writes: > ffalarms often rings with multiple simultaneous processes. Looking > around to see what was going on, I expected to find some sort of > at-command to queue the alarms, but the only at* executable is atd. > > So: > > a. anybody else seeing this behaviour from ffalarms? Hi Jeffrey, I, as the author of ffalarms see it too :), but as no one complains I can live with it. The problem is that at the moment if you set multiple alarms at the same time they all schedule new alarms and due to race condition between them you end up with single alarm scheduled multiple times. The simultaneous alarm processes try to own a dbus name, so only one should play at a time (but first schedule before owning the name so here is the race). But if dbus is not yet working (which may happen during system startup) they all decide dbus is not working and start to play simultaneously resulting in a sort of deny of service in GUI of the phone. That is a bad design of course, simple dirty hack done in a limited time, but based on an idea: it better is to set more alarms than needed than none at all. > > b. how do I view the atd queue on SHR-T? List of alarms: ffalarms -l (see http://ffalarms.projects.openmoko.org/#command-line-options) or simply ls /var/spoolt/at there is no atq > > Regards > > Jeff > ___ > Shr-User mailing list > shr-u...@lists.shr-project.org > http://lists.shr-project.org/mailman/listinfo/shr-user ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
