On Thu, Dec 17, 2015 at 10:18:10PM +0100, Reindl Harald wrote: > > > Am 17.12.2015 um 22:11 schrieb Neil Horman: > >On Thu, Dec 17, 2015 at 10:04:48PM +0100, Reindl Harald wrote: > >>Am 17.12.2015 um 22:00 schrieb Neil Horman: > >>>On Thu, Dec 17, 2015 at 03:39:17PM -0500, Colin Walters wrote: > >>>>What you're arguing is that *build* convenience for our current architecture > >>>>outweighs the *runtime* cost. That doesn't make sense long term - they're > >>>>different problems. > >>>What runtime cost are you referring to here? The cost of running systemd in a > >>>container? Its miniscule, given that its only job is to start a handful of > >>>units and get out of the way > >> > >>that's not true > >> > >>on virtual machines with no load all day long PID1 is often found as number > >>1 in htop sorted by CPU usage - multiply that with 500 and you have a > >>*useless* and well noticeable load on the host > >> > >What I hear you saying is that on a system that has nothing better to do, the > >primary monitoring process wakes up periodically to check on various system > >aspects (cron jobs, journal rotates, etc). That sounds like working as designed > >to me, not a reason to throw the proverbial baby out with the bath water. That > >seems like a reason to do some tuning. > > it is wasting ressources in a container running only one process - period - > what is there to discuss - in any serious setup there shou,ld be nothing > installed which is not *really* needed > You're making two assumptions here: 1) That there is only one process 2) That systemd (or a component thereof) isn't needed While you're use case is certainly valid, it isn't the only use case by a long shot. And if the goal for your use case is to minimize the footprint of a container, you can already do that (as I've pointed out previously) Neil > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx