[systemd-devel] How to get systemd to leave a USB serial console session alone when hadware is pulled?

Andrey Borzenkov arvidjaar at gmail.com
Wed May 22 13:09:10 PDT 2013


В Wed, 22 May 2013 02:23:45 -0700
Kaz Kylheku <kaz at kylheku.com> пишет:

> 
> On Wed, 22 May 2013 10:54:39 +0400, Andrey Borzenkov
> <arvidjaar at gmail.com> wrote:
> > Try removing BindTo. In your case you do not really want to make
> > service dependent on existence of device, only first time launching of
> > it.
> 
> Ah, okay. Very promising. I will try that tomorrow. 
> I see in the code that the inverse of UNIT_BIND_TO
> is UNIT_BOUND_BY, by means of which relationship the 
> unit of a removed device can be identified and
> stopped; to understand binding, we have to look at places in
> the code referring to UNIT_BOUND_BY as well as UNIT_BIND_TO.
> 
> I'm now concerned (hypothetically) that if the unit is
> not bound to a device, but is set to Restart=always, will
> it not just keep restarting and failing if the device is
> missing?
> 
> How about changing BindTo to Requires, instead of
> deleting it. Does that make sense?
> 

Should not it be Requisite, not Requires?

> It seems that Requires imposes a dependency for startup,
> whereas BindTo is similar, but also imposes a dependency
> on the other object for the continued operation.
> 

Requires covers voluntary state change, while BindsTo covers
involuntary state change.  

> I'm guessing that the Requires condition is
> re-checked at every restart when the service spontaneously
> dies, so that is desirable. We do want to require the device to
> be present, rather than launching "agetty" on a /dev/ttyUSB0
> which isn't there, which will only fail again and again.
> 

Requires is quite strong, it tries to start required unit. Requisite
should check whether device is "started" and simply skip starting of
getty in this case.

Requisite looks more clean, although end effect is probably the same.
Requires may result in some more stray errors in logs.

> Hmm. All will be clear when I get to experiment with this
> on the hardware back at work.



More information about the systemd-devel mailing list