<story><title>Systemd, ten years later: a historical and technical retrospective</title><url>https://blog.darknedgy.net/technology/2020/05/02/0/</url></story><parent_chain><item><author>pknopf</author><text>I&amp;#x27;m not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back.&lt;p&gt;Help me..</text></item><item><author>zozbot234</author><text>This is yet another example of pointless incidental complexity in systemd. The whole &lt;i&gt;point&lt;/i&gt; of &amp;quot;nohup&amp;quot;-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the &amp;#x27;HUP&amp;#x27; in nohup is short for &amp;quot;hang up&amp;quot; i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user session going when a program has been launched under nohup, instead it tightly couples its own &amp;quot;session&amp;quot; concept to the remote connection and then adds a totally ad-hoc, hacked-together feature called EnableLinger to somehow make nohup work anyway.  It&amp;#x27;s amazing.</text></item><item><author>ttctciyf</author><text>As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.reddit.com&amp;#x2F;r&amp;#x2F;programming&amp;#x2F;comments&amp;#x2F;4ldewx&amp;#x2F;systemd_kills_screen_and_tmux_by_default_on_logout&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.reddit.com&amp;#x2F;r&amp;#x2F;programming&amp;#x2F;comments&amp;#x2F;4ldewx&amp;#x2F;systemd...&lt;/a&gt;&lt;p&gt;Namely that systemd doesn&amp;#x27;t allow persistent processes started from the shell by default, preferring to terminate them when the user logs out.&lt;p&gt;This would include processes like &amp;quot;screen&amp;quot; whose entire raison d&amp;#x27;etre is to persist after the user logs out. (Well, it has other uses, but this is the main one IMO.)&lt;p&gt;The stated workarounds - fiddling with some options like &amp;quot;KillUserProcesses=no&amp;quot; in logind.conf &amp;amp;co. - have so far failed.&lt;p&gt;I don&amp;#x27;t know whether this situation is a problem with systemd or the distro, but it seems very much a problem with the culture summarised by the top commenter in the above thread, of (paraphrasing) &lt;i&gt;glibly breaking existing workflows then casually brushing away criticism with arguments often boiling down to: &amp;quot;this is the right way, I don&amp;#x27;t care about tradition or protecting &amp;#x27;incorrect&amp;#x27; usage.&amp;quot;&lt;/i&gt;</text></item></parent_chain><comment><author>JChase2</author><text>Slackware doesn&amp;#x27;t use it, and Patrick Volkerding recently got a Patreon account set up so Slackware 15.0 or 14.3 will hopefully be out soonish with updated packages. I&amp;#x27;m writing this on 14.2 and have been running it since it came out with basically no issues. Also have it on a backup server, runs great.</text></comment>
<story><title>Systemd, ten years later: a historical and technical retrospective</title><url>https://blog.darknedgy.net/technology/2020/05/02/0/</url></story><parent_chain><item><author>pknopf</author><text>I&amp;#x27;m not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back.&lt;p&gt;Help me..</text></item><item><author>zozbot234</author><text>This is yet another example of pointless incidental complexity in systemd. The whole &lt;i&gt;point&lt;/i&gt; of &amp;quot;nohup&amp;quot;-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the &amp;#x27;HUP&amp;#x27; in nohup is short for &amp;quot;hang up&amp;quot; i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user session going when a program has been launched under nohup, instead it tightly couples its own &amp;quot;session&amp;quot; concept to the remote connection and then adds a totally ad-hoc, hacked-together feature called EnableLinger to somehow make nohup work anyway.  It&amp;#x27;s amazing.</text></item><item><author>ttctciyf</author><text>As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.reddit.com&amp;#x2F;r&amp;#x2F;programming&amp;#x2F;comments&amp;#x2F;4ldewx&amp;#x2F;systemd_kills_screen_and_tmux_by_default_on_logout&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.reddit.com&amp;#x2F;r&amp;#x2F;programming&amp;#x2F;comments&amp;#x2F;4ldewx&amp;#x2F;systemd...&lt;/a&gt;&lt;p&gt;Namely that systemd doesn&amp;#x27;t allow persistent processes started from the shell by default, preferring to terminate them when the user logs out.&lt;p&gt;This would include processes like &amp;quot;screen&amp;quot; whose entire raison d&amp;#x27;etre is to persist after the user logs out. (Well, it has other uses, but this is the main one IMO.)&lt;p&gt;The stated workarounds - fiddling with some options like &amp;quot;KillUserProcesses=no&amp;quot; in logind.conf &amp;amp;co. - have so far failed.&lt;p&gt;I don&amp;#x27;t know whether this situation is a problem with systemd or the distro, but it seems very much a problem with the culture summarised by the top commenter in the above thread, of (paraphrasing) &lt;i&gt;glibly breaking existing workflows then casually brushing away criticism with arguments often boiling down to: &amp;quot;this is the right way, I don&amp;#x27;t care about tradition or protecting &amp;#x27;incorrect&amp;#x27; usage.&amp;quot;&lt;/i&gt;</text></item></parent_chain><comment><author>a-nikolaev</author><text>Void Linux, amazingly awesome distro.</text></comment>