On Fri, 15 Aug 2014 09:19:48 +0000 Bonno Bloksma <b.blok...@tio.nl> wrote:
> I wonder if the people developing this are paying attention to a > development in de Windows environment where the latest thing is that > de service can report back that it is indeed still trying to stop and > not just hung and not reporting back. Windows will now kill a service > after a certain time when shutting down, in some cases it was killing > a database that took A LONG TIME to shut down and cause the database > to become inconsistent. If systemd is trying to become smart about > stopping services it might be a good idea to have this built in. Also > not just have the service report back "I am still busy" but also with > a progress indicator which NEEDS to increase at each report so system > can detect whether the service is indeed progressing towards a > stopped state or hung in the getting there. > > Bonno Bloksma Yes. And why stop there? Any process that's been using a lot of processor for a long time can be nice'd up so it takes smaller slices. Each process that runs will be configured to the maximum time it can take lots of processor time. Systemd can monitor the video, so that not only typing or mousing resets the timeout, but any change in the screen resets the timeout. Some processes don't work well together, and systemd can maintain a database of such processes, perhaps in Postgres, to prevent one of those processes from running if the other is already running, unless the processes themselves tell systemd they're aware of the danger and it's OK. Systemd's database should include uuid's for specific programs known to be safe, and should not start others, unless A) The program emits a uuid to systemd upon being asked to run, and B) that uuid has been put in the database either by the distribution or by the system administrator. Before running, systemd will check the md5sum of the executable to make sure it matches the uuid. Because this might be a hardship during development, the systemd database will have a column called "lax", which, if true, allows the program to run as long as the program submits the proper password. I'm conceptually not a fan of systemd, but you have to admit it opens up many opportunities. SteveT Steve Litt * http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140815093814.07cde...@mydesq2.domain.cxm
