Understanding the role of flutter daemon

[Fabio de Matos Quaresma Gonçalves]

I recently noticed https://github.com/flutter/flutter/pull/17873 from @DanTup (Send an event at startup with the protocol version and pid) so this question may be aimed at him somehow.

I'd appreciate any links to documentation about daemons and why protocol versions exist. I'm interested in superficial questions like what does the daemon do? And can I run a range of flutter versions at the same time without bad things happening?

My typical use case:

I have multiple copies of flutter in my desktop, each one is pointing to a different channel. I have different apps that need to run on different channels. If I'm building a long term app I want it to use beta channel. If during that development I find something odd I start working on my draft app, which points to master channel. Opening issues and questions on gitter would be addressed using master channel. I usually go back and forth between these 2 kinds of projects multiple times during the day.

Should multiple daemons run at the same time (I know they do by looking at my local processes)? If no what would be the right procedure short of  `killall dart` and also killing "bash /.../flutter/bin/flutter daemon"  to bring as many daemons as necessary down? 

If not for anything else, I'd like to advocate for reproducible builds here. Once I release version x.y.z of a flutter app using flutter version w.r.t there's no need to make an incremental hotfix version of my app using the latest available on beta. Or for what matters, I don't see upgrading flutter version necessary or good practice, unless I clearly hit a flutter bug or a missing feature. But that's a separate conversion, I mentioning to give it more context to my use case.

thx

[Ian Hickson]

Each install of Flutter should be able to operate entirely independently.

The daemon mode is used by IDEs to communicate with their Flutter installation.

You can find some documentation here: https://github.com/flutter/flutter/wiki/The-flutter-daemon-mode

(If you discover that it is wrong, then please file a bug or just correct it.)

The protocol is relatively stable from version to version but no particular effort is made to maintain long-term compatibility in the protocol.

HTH,

--
You received this message because you are subscribed to the Google Groups "Flutter Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Ian Hickson

😸

[Fabio de Matos Quaresma Gonçalves]

Sounds a quite interesting piece of software. I still didn't fully understood it but I can think of a few silly ways to interact with it if I wanted to build a tool to talk to it. For example an independent Intellij plugin. It's a solution looking for a problem, but I digress.

It also reminds me of a security issue faced by Gradle 2.14, which also has a daemon to execute some of its tasks. I'm not saying flutter has the same weakness, but it may be worth checking out what it was about.

https://docs.gradle.org/2.14/release-notes.html#local-privilege-escalation-when-using-the-daemon

Gradle uses local network connections to communicate with the Gradle Daemon process. In previous versions, it was possible to detect on which local port a daemon process was listening to requests. Since the daemon process did not require authentication, an attacker on the same machine could execute arbitrary scripts using the privileges of the user who originally created the daemon. This vulnerability has been fixed in this release.

To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--
Ian Hickson

😸

--

Fabio de Matos Gonçalves

[Ian Hickson]

The Flutter daemon uses stdin/stdout to communicate to its client, so this attack vector should not be a concern. Thanks for bringing it to our attention though.

To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--
Ian Hickson

😸

--

Fabio de Matos Gonçalves

--

--
Ian Hickson

😸

[Danny Tuppeny]

I was just searching for something in flutter-dev and spotted my name in this thread; apologies I didn't respond previously!

Fabio de Matos Quaresma Gonçalves wrote:

Sounds a quite interesting piece of software. I still didn't fully understood it but I can think of a few silly ways to interact with it if I wanted to build a tool to talk to it.

To provide some additional details; in VS Code we'll spawn a copy of the (device*) daemon for each open VS Code window ("workspace") that has a Flutter project. The daemon gives us events when you connect/disconnect a device which is how we show the selected device and populate the device picker in the status bar (and more recently, how we get a list of emulators).

You'll get a daemon for each VS Code window you have open and they'll use the same version of the SDK being used for analysis/launching. So if you have three VS Code windows open that have Flutter projects, two using beta and one using master (you can quickly switch Flutter SDK folder for the current window in VS Code) then you'll have the equivalent daemons running (two beta and one master). We don't share daemon processes across VS Code windows because we communicate over stdin/stdout (as Ian mentions, this avoids some security risks because we're not binding to ports).

Hopefully, you shouldn't need to terminate any daemons even if you're running concurrent VS Code windows with different Flutter versions. The changeset you mentioned about adding the pid in a startup event was actually to fix some issues where we didn't terminate them correctly. Because "flutter" is a shell script, when we spawn it the process we have a reference to is actually a shell and the SIGTERM signal sent during shutdown doesn't get passed to the VM reliably (resulting in orphaned VM process). By exposing the pid of the real VM process in the startup event we're able to ensure that during shutdown the flutter gets the signal and can cleanup it's spawned processes too.

* As mentioned in the page Ian linked, there are actually two daemons - one mentioned above and another when running "flutter run --machine" (which lives only for the duration of the debug session) which gives us a JSON API to send hot reload/hot restart events to the running app.

I'm not sure there's much functionality exposed that would be useful to anyone that isn't writing editor integration; but hopefully the above satisfies your curiosity :-)