Systemd 238 Released, Adds New Temporary File-System Option

[Faalagorn]

Typo:

As tildearrow mentioned there's actually at least two typos in this sentence: "- A new TemporaryFileSystem= option to msk parts of a real file-system tree with tmpfs mounts. This can be used for hiding files/directories not relevant to the unity or where you don't want any rogue units to potentially access." – should be "mask" and "units" respectively . Also, the last part of the sentence lacks noun I think.

[brrrrttttt]

Really this is a weakness in current journald if you have storage=none and no forwarding running the buffers is kind of pointless but that is what current journald does. Journald not smart enough to switch to a black hole mode yet.

Agreed. Seems like a fairly trivial thing to fix on the surface but who knows what lurks beneath.

[oiaohm]

I still have a system log even on bare metal embedded stuff, although there I do it mostly with pre-processor macros. If your target is big enough to justify running Linux, it's definitely big enough to run journald. This would hopefully make it use very little resources if needed:

[Journal] Storage=none

https://elinux.org/images/6/69/Demystifying_Systemd.pdf

It was embedded developer who found you could strip out journald. Please note not having the storage with Storage=none solved one problem. But you still have journald maintaining the buffers in memory so that the forwarding to other targets could work and it was these buffers in early journald that leaked memory and hope don't leak memory again in future. Sometimes its more suitable to use a black hole logging system. So you remove journald and put in something that read the log sources and simply straight up frees them.

Really this is a weakness in current journald if you have storage=none and no forwarding running the buffers is kind of pointless but that is what current journald does. Journald not smart enough to switch to a black hole mode yet.

[brrrrttttt]

I still have a system log even on bare metal embedded stuff, although there I do it mostly with pre-processor macros. If your target is big enough to justify running Linux, it's definitely big enough to run journald. This would hopefully make it use very little resources if needed:

[Journal] Storage=none

[oiaohm]

Not to mention removing journald is frankly stupid/non-productive. For all the howling I've read about it, I've never seen a single one of the supposed "issues" actually eventuate.

I would not say removing journald is 100 percent stupid. In embedded devices where you don't have the storage in a lot cases to keep logs running journald is really consuming ram with no point. Also systemctl really does need to still work with journald missing if you removed journald and systemd failed completely that would be a bug.

There were issues with early journald and memory leaks it would have been more useful cases if distributions had bundled journald as removable and if issues turn up like that again it would still be useful.

[brrrrttttt]

Not to mention removing journald is frankly stupid/non-productive. For all the howling I've read about it, I've never seen a single one of the supposed "issues" actually eventuate.

[zbyszek]

I have a question. Is it possible to use systemd without the journal and systemd-udevd?

Without systemd-udevd: certainly. In Fedora systemd-udevd is in the systemd-udev package and systemd itself is in the systemd package. The idea is that in containers systemd-udev is not installed, there is no hardware to manage.

Without journald: not easily. There are hacks to run without journald, but tools like systemctl and coredumpctl (and journalctl obviously) all expect it to be there.

[pal666]

Is it possible to use systemd without the journal and systemd-udevd?

i remember people demanded udevd without systemd, your request is innovative

[oiaohm]

Since no one mentioned this: mosh can do this. It resumes the session when machine comes up from at least sleep. I doubt hibernation though since it's totally not safe to write authentication secrets on disk.

Mosh can live though hibernation to disc and restore back as long as your time out values are large enough. With timeouts between messages like 1 week to 30 days its really possible to put system into hibernation for quite a bit of time and mosh be fully functional after restore. Yes this does mean session is kept intact.

[oiaohm]

Please re-read my answer (or the second one, in the SO link you posted). Then, head to your nearest terminal window and type 'man screen'.

I did with modern day system using systemd screen alone is not enough. When session is lost systemd logind can step in killing everything that you have left connected to the default scope. So unless turn of systemd logind auto clean up or remember to put screen in a scope.

mosh can be a way simpler path these days. Result of mosh is the session does not collapse because the network connectivity is being broken. So you don't have to deal with logind logout out clean up.

Some send mosh over ssh to reduce number of open ports. Yes this might seam like stacking but when using in combination with autossh works quite well.

The reality screen not the best solution anymore we really need to move past using it. Mosh shows it possible to solve the connection problem and keep session alive and stable.

There is more than 1 way to solve this problem.