Originally posted by coder
View Post
Announcement
Collapse
No announcement yet.
Systemd 238 Released, Adds New Temporary File-System Option
Collapse
X
-
Originally posted by coder View PostPlease 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'.
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.
- Likes 2
Comment
-
Originally posted by nanonyme View PostSince 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.
- Likes 1
Comment
-
Originally posted by tildearrow View PostI have a question. Is it possible to use systemd without the journal and systemd-udevd?
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.
- Likes 1
Comment
-
Originally posted by brrrrttttt View PostNot 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.
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.
- Likes 1
Comment
-
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
Comment
-
Originally posted by brrrrttttt View PostI 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
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.
- Likes 2
Comment
-
Originally posted by oiaohm View PostReally 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.
- Likes 1
Comment
Comment