User: Password:
|
|
Subscribe / Log in / New account

Poettering: The Biggest Myths

Poettering: The Biggest Myths

Posted Feb 6, 2013 16:52 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: Poettering: The Biggest Myths by paulj
Parent article: Poettering: The Biggest Myths

If you have some very exotic services that use smoke signals to communicate - go on and add explicit dependencies.


(Log in to post comments)

Poettering: The Biggest Myths

Posted Feb 7, 2013 4:34 UTC (Thu) by paulj (subscriber, #341) [Link]

How would you add a dependency on, say, a location? Assume there is some daemon running on the system that can make the current location available over a socket (e.g. GPS co-ordinates, or a more abstract specification). The dependency is not just on the socket, but also on the /content/ of the information sent over that socket.

Hardly smoke signals.

Poettering: The Biggest Myths

Posted Feb 7, 2013 5:38 UTC (Thu) by khim (subscriber, #9252) [Link]

Hardly smoke signals.

It is a smoke signal - from GPS stateliness. It can easily be converted to something systemd understands if you'll create a specialized daemon (in a "true UNIX fashion" people like to preach here so much) which will convert it to signals systemd understands.

And you need such daemon anyway because you need to decide how often you poll, if you use just GPS or if you want to use WiFi, too, etc. It's not as if GPS satellites can pull some trigger on your PC or smartphone which means you'll need some complex logic anyway.

Poettering: The Biggest Myths

Posted Feb 7, 2013 5:50 UTC (Thu) by dlang (subscriber, #313) [Link]

the GPS daemon does have a socket that systemd understands, what are you suggesting? making a different socket for every possible location so that systemd can set dependencies on if that socket responds???

Just because systemd doesn't handle something doesn't mean that the something is worthless or stupid.

Poettering: The Biggest Myths

Posted Feb 7, 2013 8:00 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

If systemd cannot handle something, is there a bug report? If not, why not?

Poettering: The Biggest Myths

Posted Feb 7, 2013 8:39 UTC (Thu) by paulj (subscriber, #341) [Link]

There'll be no bug report on systemd because the applications involved are likely already using some other system. E.g. DBus IPC. DBus-daemon also can do "socket activation", and did before systemd existed I think.

Poettering: The Biggest Myths

Posted Feb 7, 2013 12:33 UTC (Thu) by khim (subscriber, #9252) [Link]

There'll be no bug report on systemd because the applications involved are likely already using some other system. E.g. DBus IPC.

If it used DBus IPC then it can be easily be used with systemd thus error report will be entirely unnecessary. I've said "convert it to signals systemd understands" and not "convert it to socket activation" exactly for this reason: because systemd handles many different activation requests and makes sure they don't conflict. Socket activation is just one of them (even if one of the most important ones).

Poettering: The Biggest Myths

Posted Feb 7, 2013 17:02 UTC (Thu) by paulj (subscriber, #341) [Link]

Interesting, thanks. :)

Bit of a dance, to have the IPC nexus hand-off this activation. It feels like really these should be part of one thing...

Poettering: The Biggest Myths

Posted Feb 7, 2013 8:25 UTC (Thu) by anselm (subscriber, #2796) [Link]

The GPS daemon provides the current location on a socket. It is probably unreasonable to expect systemd to be able to deal with that sort of information directly (systemd detractors would immediately jump on features such as these and call them out as »bloat«, with some justification).

Hence, a reasonable way of handling this would be to write a (not very complicated) subsidiary daemon that listened to the GPS daemon's output and triggered various systemd actions based on them. This might be a good idea in any case in order to provide »smoothing« of the location data or additional rules (»tell me about bars in the vicinity but only during happy hour«). This daemon itself would of course be managed by systemd.

This approach should also please the Unix traditionalists who insist that programs should »do one job and do it well«.

Poettering: The Biggest Myths

Posted Feb 7, 2013 8:35 UTC (Thu) by paulj (subscriber, #341) [Link]

So, go on, how do you expose that dependency in a way systemd can handle it. Tell me.

(FWIW, I have no opinion generally on systemd - I don't know enough about it. I'm just a tad sceptical of the wonder claims being made for socket activation based dependency resolution).

Poettering: The Biggest Myths

Posted Feb 7, 2013 8:59 UTC (Thu) by cortana (subscriber, #24596) [Link]

Perhaps you could create target units for each location of interest; other units could then be wanted by/conflict with each target in order to be started/stopped when the location is changed. You would need a glue daemon to look at the GPS data and decide when to start/stop the location targets.

Poettering: The Biggest Myths

Posted Feb 7, 2013 12:41 UTC (Thu) by khim (subscriber, #9252) [Link]

So, go on, how do you expose that dependency in a way systemd can handle it. Tell me.

Well, as you've suggested: DBus activation looks like a natural fit for such a use case - and since systemd handles it just fine... I don't see what's your problem.

I'm just a tad sceptical of the wonder claims being made for socket activation based dependency resolution.

Socket activation covers 90% of usecases, but there are other ways to activate service. And the important thing of systemd is that they all can be used simultaneously. You can start some daemon at specific time (using time-based activation) and when your a leaving specific area (D-Bus based activation) and when some other service needs this particular daemon (socket-based activation). They don't conflict and handled correctly in all cases.

Socket activation is there to track dependencies between services on your own system: it's the simplest one to use and most robust one. But there are other to handle "smoke signals", too.

Poettering: The Biggest Myths

Posted Feb 7, 2013 12:19 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Don't use socket-based activation and do your dependencies manually, just as in the SysV world. Simple.

Additionally, designer of such a crazy interface should be shot immediately to stop propagating bogosity.

Poettering: The Biggest Myths

Posted Feb 7, 2013 15:59 UTC (Thu) by dlang (subscriber, #313) [Link]

> Don't use socket-based activation and do your dependencies manually, just as in the SysV world. Simple.

Then why is it that when people talk about doing exactly this, they get jumped by systemd people saying things like "why didn't you submit a bug report to get that capibility added to systemd" or "that's a stupid way to do things, you need to re-write your software to use systemd to do it"

This subthread started by the simple statement that socket-based activation was not always appropriate, with the acknowledgement that systemd could support this.

Poettering: The Biggest Myths

Posted Feb 7, 2013 16:03 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> Then why is it that when people talk about doing exactly this, they get jumped by systemd people saying things like "why didn't you submit a bug report to get that capibility added to systemd" or "that's a stupid way to do things, you need to re-write your software to use systemd to do it"
These advices are not mutually exclusive, you know.

If you have a compelling use-case of some exotic activation system for which it makes sense to add core support then doing a bugreport might be a good idea.

And in other cases it might be a good idea to simply rewrite the offending code.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds