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