Effects of blocking systemd via INSTALL_MASK

[Hu]

According to separate-usr-is-broken (which starts by stating that systemd works fine with separate /usr), the problem is that various projects integrated with udev, but did so in a way that expected /usr to be available. Udev provided only the minimal handling required not to explode when /usr was not available, and those projects would later have strange failures caused by udev skipping their rules when /usr was unavailable. The possible fixes for this were:

• Declare separate usr to be broken, refuse to support it at all
• Teach udev how and when to defer usr-requiring rules until after usr was up
• Stop placing /usr-dependent rules in a context where udev tries to run them before /usr is ready

As in most software projects, declaring a use-case unsupported and refusing to deal with it is by far the easiest solution. Of course, having done that, the political base is laid for the technical changes krinn describes, even though those changes are unnecessary and potentially counterproductive.

[khayyam]

[jd2066]

[khayyam]

[jd2066]

[Tony0945]

Admitting that I haven't studied these issues but just went with the flow on these changes, I do wonder:

1. Why not leave /var/run as a tmpfs instead of creating /run which didn't have to be at root level because at boot time it only contains trash, if that.
2. Why not switch /var/lock to /var/run/lock so that locks disappear after boot?
3. Can't comment on /dev/.[program] because I never heard of it before, but what are hidden directories/files doing in /dev at all? That's for device files and symlinks to device files.

[jd2066]

[khayyam]

jd2066 ... I think you're missing the point, when things run in early boot they create whatever files they need, whether in /dev/.* or /run/* it matters not (except perhaps that /dev/ isn't intended for such things) ... /run makes perfect sense in this regard. But some programs (not part of "early boot") expect a filesystem, and don't create that filesystem, because they have hitherto been served by the non-volatile nature of /var/ or were sufficiently handled by initscripts. So, by relocating /var/run to /run you require there be some mechanism to create this filesystem, as this may previously had been handled via initscripts, or via the package manager. Now, what mechanism should this be? The package manager can't help (except perhaps install something to tmpfiles.d) because the filesystem in question doesn't survive reboots. Initscripts then, as that's their purpose (to bring the system/service up into a working state), but systemd doesn't have initscripts, and systemd is the "standard" for how things should be done ... so, we come to tmpfiles.d.

You might want to 'grep checkpath /etc/init.d/*' and look see what's done for /var/ and/or /run. You'll probably see that for most cases we are making sure the required filesystem is available, and has the correct ownership/permissions. Similarly with other tasks, clearing /tmp for instance.

best ... khay

[jd2066]

[khayyam]

jd2066 ... again, I think you're missing the point, you seem to be looking at this from the point of view of what systemd does, when for me, my focus is on what my system is doing, or needs to do (and the best methods to achieve that). Yes, it may have been the package manager, or the initscript, that provided the filesystem prior to their relocation to /run, but the question is what is the actual benefit (to me) with the introduction of tmpfiles.d? Was something "broken" previously, and is this mechanism more robust? IMO, no, there wasn't a problem that necessarily needed solving, and practically the only instances of which I read there being one (ie, "screen") these are cases under which the application, or user, should change (ie, 'TMPDIR=~/tmp screen') ... if only because the negatives of the change outweigh the positives.

best ... khay

[jd2066]

[krinn]

I think you are missing some point:
- /dev was use to store early boot infos ; but it was bad, first because you start adding more and more .something in /dev that is not related devices, but they were doing that because udev was using /dev on tmpfs, which is broken from the very start, because you are using /dev assuming it is tmpfs, which is only true if udev handle it ; static /dev does not do that.
- /var/run was a bad answer to that: they saw they need to have a dedicated tmpfs to handle early boot processing, but they pickup /var/run which is totally wrong: /var may get mount later from another disk/partition or nfs, if anyone mount /var/run as tmpfs and write early boot datas in it, once the real /var is mount, all the informations are lost.
- /run is the only correct answer: you make a tmpfs that even static /dev user will create, it is a direct directory depending on / which is the only 100% sure mount point that will be always there, it is a directory that LFSH didn't speak of prior to its creation, and as such nobody should had use that directory (so you are avoiding using /run that was use for something, and avoid anyone mount /run after boot) ; assuming everyone has comply with LFSH and wasn't using stupid subdir names in their /
- tmpfiles.d is another stupid creation made on a not bad idea:
program need temp file, they need them when they run, but don't care i they doesn't exists when they start.
but using temp file is not that easy:
You have to use a file nobody is using already, to not fuck the other program, and to prevent the other program doing the same on you. No big deal you check filename exists and if not, it's for you.

But you have an issue: when your program crash (or someone doesn't remove the file on program exit), the file remain in /tmp, and on your next run, you will see the file exists and pickup another name.
and /tmp start to get unused files (which might be big) and the system is loosing space.
You can mitigate this in two ways:
* clean /tmp when you boot, but the problem is that you do that only when you boot (funny it shouldn't be a problem at all for a server using systemd, as any update to systemd need a reboot) ; so it's a false problem to clean /tmp only on boot for systemd, because rebooting should happen a lot. But it could be one for a system that is running for a long time without reboot.
* clean /tmp every X delays (say, using cron), but you have no idea if the file is "still in use", you are remove a file from /tmp that a program is using, it's not because the file is X days old that the file is not use.

To solve this, systemd introduce tmpfiles.d but as usual with systemd, it has done shit again.
So they say: we will not allow anyone to clean /tmp and we will delegate that task to tmpfiles.d, program install a "tmpfiles config" and tell their usage of a temp file (how much time the file should survive), and tmpfiles.d create wanted file for the program with wanted attributes (mode, uid and gid), and handle the cleaning thru an "age" value.

This is totally stupid:
- this doesn't solve filename clash, programs ask tmpfiles to create /tmp/this but if /tmp/this already exists with the good properties, you shouldn't use it, but tmpfiles.d will not handle the clash, it's still upto your program to do that.
sshd ask "/tmp/sshd_1", tmpfiles.d answer "no, this file exists", then it's still upto sshd to then redo, "ok what about /tmp/ssh_d2 then", and tmpfiles.d will say "yes or no".

In theory it works, after few times, /tmp/sshd_1 will reach its age limit, and so tmpfiles.d will clean /tmp/sshd_1
But this is totally broken, it mean if your running sshd is using /tmp/sshd_1 and it has reach its age limit, good bye /tmp/sshd_1 and go luck to handle that ; while virtual fs will keep its content for sshd, you won't see it yourself, and /tmp/sshd_1 content may still be "ok" for sshd because it was using /tmp/sshd_1 and set its content to "ok", but if you look at /tmp/ssd_1 content yourself, you will see its actual content, that is the content another ssh_d instance is using and have set to "not ok".
so you have an sshd pid10 using /tmp/sshd_1 and set "ok" in it, and after x time, tmpfiles.d has remove the file, you start another sshd with pid2000 and it reuse the file (because the file no more exists for sshd pid2000, while still sshd pid10 is still using it!) and set it to "not ok". But when you look at the file content you will see it's "actual" state, so you see "not ok" yourself.
Not only it will harder debug, but it's prone to errors and security issue.
So this is a an issue for an file that you have keep open.

But if your program close the file to reuse it later, it's worst.
You create the file, use it, close it, and reopen it later again (you don't delete it, you will need its content later).
This time virtual fs won't come to your help: sshd create "/tmp/sshd_1", use it, close it, do some stuff, tmpfiles.d see "/tmp/sshd_1" has reach age limit and clean it ; now your sshd will try reopen the file to reuse what you have stored in it ; but wait, the file is gone! Good luck handling that...

Because stupidity has no limit with systemd, they also think, "oh but what about files we have no config for?" and the result is:
default rule in systemd: if a file age is 30 days and no config exists, clean it.
And that's the issue portage has get, in order to save /var/tmp/ccache from cleaning by this stupid rule, they want add a portage_ccache tmpfiles kind of config file to say "stop cleaning /var/tmp/ccache every 30 days"

Instead of gay config files everywhere for each program, it should had use a centralized base itself and handle file creation/deletion and pid owner.
It would had been nice that your program would do
hey tempfiles.d, i need a temp file, tmpfiles.d choose itself the filename (handle name clash and in use file), create the filename... and return "ok here's the one you will use".
no age limit: each time tmpfiles.d gave a filename, it record: ok i have create file "z" for sshd-pid34, if next time someone ask me something, i will check that sshd-pid34 is still running and if not, and the file is still there, i'll clean it.
if anyone ask me a file, i will make sure to gave him back a file name that doesn't exists.

no need for config file everywhere, tmpfiles.d would use a database to keep file use by each pid.
and a default sane rule with : if i see a file in /tmp, if i know i have create this file, and if the program/pid that has ask me that file is no more running, i'll delete it.
This way, if tmpfiles.d see a file that wasn't create by it, it keep it, if it is one it has create, it clean it if the pid owner is no more running.

And you don't gives a fuck if pid is running since two years or if a file in /tmp is 10 years old or not, still, you are able to recover space from /tmp for each file tmpfiles.d has been ask to create, and you never remove a file that is use by a running program. And if the program crash or forget to ask it delete, tmpfiles.d is able to clean it by itself ; and this without removing a file that is in use, and without removing a file that you don't handle and that may be important even nobody has telling you about it, and still ease temp files name creation and deletion, with the benefits to claiming back space from no more used files.

Not a bad idea at first, but badly implemented, and again with tones of .conf files everywhere for nothing in the pure spirit of .ini files Windows love.
ps: note that i have no idea how systemd-tmpfiles is implement really, that's only how it is implemented in opentmpfiles.d, which mean, systemd version might not be as useless as openrc one.
Like it is actually, it's only value is : create a configfile that set age value of a cache file, and when age is reach, clean it so the cache file is force to refresh ; however, even in this case, it mean the cache file could be clean while the program is trying to use it, with unexpected results and "racing condition" bugs, totally lame.

[Tony0945]

[khayyam]

[jd2066]

[khayyam]

[jd2066]

[krinn]

[khayyam]

[jd2066]

[jd2066]

[khayyam]

[jd2066]

khayyam: I have tried to understand what point you were you attempting to convey with your posts but still just don't get it.
I think I'll just have to end this discussion as it seems to be a fruitless discussion.

[khayyam]

[jd2066]