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.

1 Like

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:

https://git.launchpad.net/ubuntu/+source/systemd-shim

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:

https://www.linuxfoundation.org/blog/2013/08/all-about-the-linux-kernel-cgroups-redesign/

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.

1 Like

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.

Exactly @ zyga-snapd … If you track the top distros, all the #1 distros that have trended over the past six years have all been systemd-less or systemd-optional distros. This gives a pretty clear indicator of what the world wide Linux community thinks about requiring systemd for anything.

Linux is about choice and the UNIX philosophy. Not mandates.

1 Like

[[CITATION NEEDED]]

If you’re talking about distrowatch as your measure of which distros are “trending” I have a bridge to sell you. Also a blog post explaining why distrowatch is not a measure of popularity.

1 Like

You don’t need to read some blog post about it, DistroWatch specifically states they don’t track popularity or usage statistics right on their website: https://distrowatch.com/dwres.php?resource=popularity

The point though remains, Snap is not a portable Linux package format, it’s a systemd package format. Which means outside of the corporate side of things there isn’t much interest in it. SUSE and Red Hat mostly use Flatpak, which means Ubuntu is pretty much the only distro interested in Snap.

1 Like

Hey @popey
I"m just researching how to run snap without systemd (a requirement that doesn’t really makes sense on a modern cgroups kernel). I didn’t intend for this to turn into yet-another-systemd-flameware. However… here we are…

Your argument is playing on the old “correlation does not indicate causality” claim, which, if pulled from the context of the living breathing Linux community, could true. However, upon closer inspection of the Linux community and its desires, your underlying point falls flat. While top-hits-per-day DOES indicate curiosity (not popularity), this is also is NOT the only indicator.

Another significant detail that actually matters is what is IN that #1 spot, and how strong this curiosity is. This #1 spot has been solid, non-systemd distros (for at least the last 6-8yrs), but this non-systemd/#1 hit-rate slot is also usually 2x or MORE the next most clicked distros.

But that’s not everything… if you really want to see what people are actively looking for… one of the biggest search feature requests (in the DW advanced search tool) the init category has been the init package of “Not systemd”.

This fact illustrates the codified request for not only for what people are looking for, but what they want to exclude. There are no other implemented NOT X options, anywhere on distrowatch (other than Not-based-on-distro).

For example, after Deb/Ubuntu adopted systemd, this is what drovee Linux Mint 17 to the top of the list… then once Linux Mint 18 enforced systemd, this is why it lost #1, dropepd dropped down, and other systemd-free distros like Devuan and MX Linux quickly took #1 slot. The community behind these trends is also why articles like this and this are still being written today .

These indicators all taken together paint a pretty clear picture, that since at least since 2013, a large % of the Linux community is driven by the ongoing hunt for non-systemd distros.

Linux people want choice, and systemd == !choice.

T.Weeks

1 Like

As I explained in the blog post. The reason MX is in the number one spot is mostly because it’s in the number one slot. It’s a self-perpetuating rank. Click on #1 and that’s counted, and makes #1 goes up. This was confirmed by DW owners to me themselves. It’s not a measure of people using it, or desiring to use it. It’s mostly just people on the site, clicking links which are internal, and count. Nothing more.

Nope. Not even close. Millions of people use systemd based distros including Ubuntu, Linux Mint, Fedora, Manjaro and many others. The number of users of the excellent but more niche distros which feature non-systemd is nothing like the numbers the systemd distros have.

I am not arguing that snap shouldn’t support something other than systemd, merely that you’re using flawed data to prove there’s a significant userbase to cater to.

1 Like

Hey did you solved problem? I’m in devuan and also snapd is banned . How do you got ? Can i compile snapd without systemd from source

Hi,

i am not quite sure but if you dont have systemd cant you just use classic init.d system (that thing that systemd is backwards compatible to)?

like sudo /etc/init.d/snapd start

but it lookes like there is no snapd in init.d, maybe it is possible to write one (ike search for lsb init.d file format)

that just starts /usr/lib/snapd/snapd

or just try

sudo /usr/lib/snapd/snapd &

im just guessing here…

T

To just start snapd you could indeed, but there is a lot more systemd technology used…

Snaps are readonly squashfs filesystem images, when they get installed a systemd mount unit is generated so that the filesystem image gets loop mounted under /snap in your filesystem…

If a snap contains services, systemd daemon units are generated at install time to manage these services…

You would have to patch snapd and write code that does all the above in a sysv-init compliant way to actually replace the systemd requirement…