Installing and running snaps without systemd

AFAIK there’s nothing ubuntu-specific; what I’m saying is that getting it to work is a lot of fiddly integration work, that I’m very glad somebody else did, and I have no plans of learning how to do because it’s a nightmare.

Let me boot 14.04 to check… 204-5ubuntu20.31.

Hi there. I run a non public distro which doesn’t use systemd and has absolutely NO issues with running systemd containers , non degraded in your lxc say. I am now testin this snapd, and tsk tsk,… you first resisted joining systemd, now you did and this ‘coding for one mistake down the line’ init kinda thing will only end up shooting you in your own foot. But ok. Anyway, I don’t understand about the namespace, as I can run that fine in my system… a mount option command is not systemd specific so will not be a problem on non systemd… now, instead one has to code to undo your systemd specific stuff… sigh. Makes me smile though reading how ‘this doesn’t depend on systemd’… from the way you guys are coding it does… Now, I have to maintain ‘go’ , whatever language that is… this is just like pretyt much every other ‘project’ to modernise in the past 10 years… wayland, ninja, meson, llvm, nothing but issues… and complaining about the old… I cannot imagine if all those software hours of coders in the past 10 years went to improve existing code instead of all the new garbage , where we would have been today! But oh well. it’s not too hard to patch silliness.

Walking from A to B has always been fine …

Then someone invented the horse cart and suddenly you could do A to B in the quater of the time… sadly now you’d always step into horse manure when crossing the street …

Progress comes with issues, yet you wont stop it, life is progress, arrange with it … :man_shrugging:

If you want to use snaps without systemd i’d suggest taking a deep look at the past in Ubuntu 14.04 … and particulary at:

No need. Indeed, progress. 10 years of laughable stuff… the proverbial manure as you say. Example of the quality of the coders messing this up… first file I looked at said:
Oh, we need cgroups, so we can’t mount without systemd or something silly… “lol”… a kernel feature, not a systemd feature, no wonder you have it so backwards…and then a ton of “systemd checks” to make a kernel thing , which should be agnostic work… C’mon canonical, we all know you can do better than that. systemd references? over 1000 , a guesstimate after removing comments potentially. Hey, ubuntu want to lock themselves into systemd, no problem… most public distros do. Progress happens regardless in the backgrounds. But thanks for tips. most of the time, ‘shims’ are a way of doing A (+b) (-b) = C… erm… = A.

One of the restrictions with cgroups on modern kernels is that each cgroup should be managed by a single writer. This model pretty much requires that there be a user space component that manages at least the root cgroup and offers an API to perform operations on behalf of other processes. On modern Linux systems, that agent is systemd. You can see some details about this here:

So it isn’t a simple matter for snapd to bypass systemd and work directly with the kernel interface. It isn’t clear you’d want snapd directly fiddling with the cgroup hierarchies on a non-systemd system either, since you wouldn’t want it to monopolise the kernel feature there either.

1 Like

Hi Jamesh, yes, a fair comment and assessment. I was there when you guys were working on upstart and esp. in lxd, stgraber et al. working with the cgroups and vs. ‘systemd’ and so on. In the end the battle was settled and most distros use systemd. Yes, I get it, and that’s fine for now. I don’ mind that but certain things work against systemd, maybe some don’t think so but I am not so certain it’s necessarily the ‘set in stone’ forever after. I won’t go into it now but haven’t used it for 3 years and couldn’t have a better system. If snapd is a good technology, then we will convert it into non-systemd, no problems.

I just am surprised at some of the lack of agnostic implementation here and there when it’s probably a good thing. Again, people like to go all in these days, especially the past decade. Wisdom has shown time and time again, humans go "Oh, ye… ok… so things didn’t pan out entirely how we envisioned’. Anyway, cheers.

My point wasn’t that every Linux system should use systemd: rather than a non-systemd system that wants to make use of cgroups will need some user space agent that can coordinate access.

I doubt you’d want that agent to be snapd, and I don’t think the snapd developers want to take on that kind of responsibility either (especially since it would not be used by the vast majority of systems it is installed on).

Hi again. Yes, this is obvious. We do not use snapd, it is just a project, that if looks good, will be added for inclusion. Under no circumstance would cgroup management be delegated to “system third party agents”, e.g. snapd scripts, or other scripts, (nor systemd, for that matter, since in our systems, that is not anything). That is to say, yes, additional interfaces to our cgroup management and external project like snapd needs to be written… which is what my initial comments regarded. But it’s all good. Thanks for the input.