3 ms·

cgroups are essential to properly limit daemons on baremetal servers without the overhead of containers (so more bang for bucks). For example, you can make sur

cgroups are essential to properly limit daemons on baremetal servers without the overhead of containers (so more bang for bucks). For example, you can make sure some poorly written python daemon will never use more than 50pct of the cpu or over 1 Gb of ram - and systemd services will nicely restart the daemon if\when that happens. By not using systemd you are depriving yourself of essential tools in modern sysadmin (timers alone are worth switching to systems compared to cron anachronistic hacks)

dijit 8y ago
You can use cgroups without systemd. Them being released at similar times does not mean systemd implemented them, they exist completely separately to systemd. Literally: mkdir /sys/fs/cgroup/memory/<groupname>; echo 100000000 > /sys/fs/cgroup/memory/<groupname>/memory.limit_in_bytes is all you need for cgroups.
- devereaux 8y ago
  Sure, then you need to write scripts to monitor your daemons and their dependencies, and you may end up writing something likely worse than systemd that just suffers from the 'NIH' syndrome. Adjusting to systemd took me a while, but I believe it was worth the effort, and I also believe most people who dislike systemd are just set in their old ways
  - nwmcsween 8y ago
    Other way around there were daemons that previously managed cgroups and system NIHed a new implementation.
- Xylakant 8y ago
  The grandparents comment was targeted at cgroups in general. You can’t use cgroups without cgroups. To add on that: IMHO, both systemd and docker made cgroups much more accessible to joe sysadmin and while they’re not a bulletproof security feature, having them (and capabilities, another kernel feature exposed by systemd) in wider use is generally a good thing.
  - dijit 8y ago
    > cgroups without cgroups. I've been charring my brain to understand what you mean by this. You don't need to have cgroups for all applications in order to use them. And they don't need to be implemented by systemd specifically for them to be in use by other init's or tools. SystemD existing (and being pushed so heavily) stymies the rise of such init systems.
    - Xylakant 8y ago
      The post I was referring to criticizes cgroups in general, regardless of how they are managed or used.

dijit 8y ago

You can use cgroups without systemd. Them being released at similar times does not mean systemd implemented them, they exist completely separately to systemd. Literally: mkdir /sys/fs/cgroup/memory/<groupname>; echo 100000000 > /sys/fs/cgroup/memory/<groupname>/memory.limit_in_bytes is all you need for cgroups.

devereaux 8y ago
Sure, then you need to write scripts to monitor your daemons and their dependencies, and you may end up writing something likely worse than systemd that just suffers from the 'NIH' syndrome. Adjusting to systemd took me a while, but I believe it was worth the effort, and I also believe most people who dislike systemd are just set in their old ways
- nwmcsween 8y ago
  Other way around there were daemons that previously managed cgroups and system NIHed a new implementation.
Xylakant 8y ago
The grandparents comment was targeted at cgroups in general. You can’t use cgroups without cgroups. To add on that: IMHO, both systemd and docker made cgroups much more accessible to joe sysadmin and while they’re not a bulletproof security feature, having them (and capabilities, another kernel feature exposed by systemd) in wider use is generally a good thing.
- dijit 8y ago
  > cgroups without cgroups. I've been charring my brain to understand what you mean by this. You don't need to have cgroups for all applications in order to use them. And they don't need to be implemented by systemd specifically for them to be in use by other init's or tools. SystemD existing (and being pushed so heavily) stymies the rise of such init systems.
  - Xylakant 8y ago
    The post I was referring to criticizes cgroups in general, regardless of how they are managed or used.