[systemd-devel] Needs help for on charging activation

[Kyungmin Park]

On Thursday, March 19, 2015, David Herrmann <dh.herrmann at gmail.com> wrote:

> Hi
>
> On Mon, Mar 9, 2015 at 3:21 PM, WaLyong Cho <walyong.cho at samsung.com
> <javascript:;>> wrote:
> > Hi,
> >
> > I want to find best solution on our case. Our product is mobile device.
> > But I don't think that is only problem of mobile device. That also can
> > be problem of laptop. So, please comment to me.
> >
> > We have some of services are always running after system is started up
> > as default. They don't need to be running always. They are just needed
> > only charger is plugged in.
> > So I thought lets only active them when only charger is plugged in.
> >
> > I thought two methods.
> >
> > method 1:
> > Charger also can be detected by udev. So udev hardware activation can be
> > used.
> > I wrote below udev rules.
> >
> > SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_CHARGE_NOW}=="1",
> > TAG+="systemd", ENV{SYSTEMD_WANTS}+="foo.service"
>
> I guess the problem is, the .device unit is never stopped. Therefore,
> when you unplug it, it will not be stopped, as the device is still
> there.
>
> You could try this:
>
> SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_CHARGE_NOW}=="1", \
> TAG+="systemd", ENV{SYSTEMD_WANTS}+="foo.service", \
> ENV{SYSTEMD_READY}=1
>
> SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_CHARGE_NOW}=="0", \
> ENV{SYSTEMD_READY}=0
>
> It's not particularly nice, as other dependencies on the power-supply
> device will now be borked. But as a hack it should work.


There are some hard test-case. Connect & disconnect within short time and
several time. Then does it handle it at udev activation based
service launch?

Another one is that there are lots of services has dependency with
charging. Then dose it add it all cases like above? Doesn't better to use
target? E.g., charging.target?

Thank you,
Kyungmin Park

>
> I cannot think of a better way to support udev-activation based on
> attribute-changes. We never explicitly supported it. Hmm..



> Thanks
> David
>
> > It looked working well. foo.service is only activated when charger was
> > plugged in.
> > But I have some of problems with hardware activation.
> > I want to be stopped foo.service when the charger is plugged out. As I
> > know, this is impossible with udev hardware activation.
> > To do this, foo.service have to determine the charger state itself and
> > if the charger is plugged out, it have to stop itself.
> > And it is working only at the first time.
> > After foo.service was activated, I stopped foo.service by "systemctl
> > stop foo.service". And plug out and plug in the charger again. Then
> > foo.service was not activated. (Is it normal? I did not try to find the
> > reason. If you say it's a problem, then I will try to find.)
> >
> >
> > method 2:
> > We have another device daemon. Let's call that as deviced and its
> > service name is deviced.service. deviced know about plug in/out of the
> > charger.
> > So, I made a new charging.target. foo.service have Wants= dependency for
> > charging.target. (Installed on charging.target.wants.) And I added
> > "BindsTo=charging.target" to foo.service.
> > Then foo.service is activated well when the charging.target is entered
> > to active state. And also deactivated when charging.target was
> deactivated.
> >
> > In this method, there are limitations what some of other daemon is
> > needed and new charging.target is needed.
> >
> >
> > Is there any more good way for this?
> > I want to find best appropriate way.
> >
> > Thank you in advance for comment.
> >
> > WaLyong
> > _______________________________________________
> > systemd-devel mailing list
> > systemd-devel at lists.freedesktop.org <javascript:;>
> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org <javascript:;>
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150319/a3e687e7/attachment-0001.html>