Foris controller processes

Software SW bugs discussion
1

Not sure if this is a bug, but I have 17 instances of foris-controller running on my Turris Omnia.

root@turris:~# ps w |grep foris-controller
 2201 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 3605 root     13916 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4068 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4069 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4070 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4071 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4072 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4073 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4074 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4075 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4076 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4077 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4079 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4080 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4081 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4084 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run
 4085 root     15084 S    python /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock ubus --path /var/run

Is this normal? I also have python /usr/bin/foris -s flup -a config and python /usr/bin/foris -s flup -a wizard.
I don’t use the foris webinterface but prefer luci so is it safe to disable? Or are these processes doing other tasks as well besides the web-interface?

2

There are config files for foris in /etc/lighttpd/conf.d (foris-wizard.conf, foris-config.conf) which are used by webserver to serve http://192.168.1.1/config and http://192.168.1.1/wizard pages. Remove what you do not want and restart lighttpd service.(i’ve already removed that foris-wizard.conf, so far so good).

… and you can also uninstall Foris as package via opkg, but that might bring some more issues later on when there will be new TOS upgrade. And some new features are only there (easy-openvpn, pakon, cloudbackups, storage …) so it is sometimes handy to have it running :slight_smile:

3

Thank you, but knows anybody, if approximately 20 /usr/bin/foris-controller processes are needed?

4

bump

I noticed python /usr/bin/foris -s flup -a config is using 50% cpu on my omnia. It didn’t do that before but now it does, consistenly.

5

Any progress on this?

I’m having the same problem, except that it’s using so much cpu that the foris web interface isn’t displayed for a long time. Lag of more than 40 seconds.
Similar, I had to try three times with ssh before I managed to log in.
Top, when it finally displayed anything, revealed the /usr/bin/foris-controller process on most locations.

Only a reboot seems to work - for a while… :frowning:

6

Hi, same thing here.

I have a brand new Turris Omnia, updated to the latest version as of October 23, and while I don’t see performance degradations yet, top constantly looks like this or similar:

Mem: 194584K used, 1875700K free, 708K shrd, 3524K buff, 53080K cached
CPU: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq
Load average: 0.00 0.01 0.00 1/177 4485
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
4477 3826 root R 1136 0% 0% top
2768 1 root S 35544 2% 0% /usr/bin/kresd -c /tmp/kresd.config -
2562 2417 root S 15504 1% 0% python /usr/bin/foris -s flup -a conf
2606 2407 root S 15124 1% 0% python /usr/bin/foris-controller -b o
2568 2417 root S 14940 1% 0% python /usr/bin/foris -s flup -a wiza
2593 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2607 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2595 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2598 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2597 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2594 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2602 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2596 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2605 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2599 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2601 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2604 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2603 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o
2600 2407 root S 14728 1% 0% python /usr/bin/foris-controller -b o

What are all these foris-controller processes there for, and why are there so many?

So far, I realized that if I issue “/etc/init.d/foris-controller stop”, they, well, stop running, but then the default configuration interface won’t work either (the advanced luci interface still continues to work, though).

So again, why are there so many different foris-controller processes constantly running and requiring CPU?

Thanks for answering.

7

Hi,

it is an expected behavior. Foris-controller registers objects on ubus within a different processes. So there is a single process per ubus object (plus one extra process). Note that the main process is forked so the separate processes share the most of the RAM (copy on write).

The reason why this is done is to achieve some kind of parallelism (among ubus objects). Note that when a single request is served by ubus object the entire process is blocked until the request finishes (or a timeout occurs).

1 Like
8

Hi Stepan,

thanks a lot for the quick reply and the thorough explanation!

I still find the behaviour mildly confusing, but I guess I can live with it.

Anyway, thank you and all the folks at turris/nic.cz for the awesome product, and for your continued great work!