Nope:

[user]@[host]:~$ systemd-run --scope --user screen

Job for run-r0b2a43d19a564e2c9f36b5c9b934420f.scope failed.

See "systemctl status run-r0b2a43d19a564e2c9f36b5c9b934420f.scope" and "journalctl -xe" for details.

[user]@[host]$ journalctl -xe | cat

May 04 03:02:54 [host] systemd[918]: Failed to start /usr/bin/screen.

-- Subject: Unit UNIT has failed

-- Defined-By: systemd

-- Support: http://www.ubuntu.com/support

--

-- Unit UNIT has failed.

--

-- The result is RESULT.

May 04 03:02:54 [host] polkitd(authority=local)[879]:

Unregistered Authentication Agent for unix-process:1504:595444 (system bus name :1.25, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) (disconnected from bus)

----------------------------

I changed my user and hostname to "[user]" and "[host]" respectively, the rest is verbatim.

It's interesting to note that to even see the error report (such as it is) I'm instructed to invoke a special command rather than just look at logs where I might expect to find it, and that when I do so I am locked into some dysfunctional pager requiring me to pipe through "useless cat" in order to cut and paste the uninformative details on long lines.

While the consistent boorishness of my systemd install continues to amuse, the details of this issue and the fact of its resolvability or otherwise by invoking recondite special systemd functionality are beside the point.

Why should I need to know how to run normal and trusted software in special systemd compatible ways that I've previously had no issues with for decades?

As I opine below, the point is the toxic "you're doing it wrong" mentality that infests the systemd project and its adherents. I've run into this in so many ways since ceding defeat and allowing it onto my systems. This is just the latest in a long line of examples.

> As I opine below, the point is the toxic "you're doing it wrong" mentality that infests the systemd project and its adherents.

Ha, if only that behavior was confined to systemd... I am forced to consider it a defining feature of much of the OSS/Unix community.

Systemd is mild compared to many projects and its adherents in this regard.

It might be this issue https://bbs.archlinux.org/viewtopic.php?pid=1724323#p1724323

I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon.

I see this kind of talking about stuff like the Unix way and existing conventions and programs. I almost have to ask myself when did we end up in a mausoleum. The Unix way is just a guideline from a time some folks wrote some code. A seminal and important time. Its just one(perhaps of many) piece of anecdata. Old code is old code. It's useful but the patterns and conventions it was built on may no longer be relevant. It is not obvious apriori that it is worthwhile to preserve existing conventions and not break existing code.

The conventions "Do one thing and do it well", and "Don't break the user experience" are not threadbare or shabby. Not UNIX nor its derivatives did spring fully formed from the foreheads of K̶n̶u̶t̶h̶ Thompson or Ritchie; it was written as a series of counterpoints to the prevailing designs and implementations of the day.

To us the ashes of our ancestors are sacred and their resting place is hallowed ground. You wander far from the graves of your ancestors and seemingly without regret.

Donald Knuth was not a designer of Unix, and he is still alive.

Also, Linux is not Unix and was never intended to be Unix or follow its conventions.

The way Linux works now seems sane. You might very well have seen a change in the way Linux works. But when you've seen it change, multiple times, and each time 50% of what you know has to be tossed out and relearned, it gets tiresome. At times it just seems like it's change just for change's sake.

I want to have fun with the computer, not run madly just to stay in place like the Red Queen. Remember to re-read your own comment 30 years from now and see if you feel the same way.

It's a good question and infects all of our software "sacred cows."

The underlying thing is that we keep driving ourselves to "forward progress" in the sense of a collaborative hegemony, and only in those terms. Either a business wants to own the platform, or the developer wants to build that platform. To do that they have to achieve buy-in from existing stakeholders, but simultaneously reinvent incompatible things. Thus through repeated application of this approach the world of professional software development has aggregated itself into conformance to standards that barely make sense, are poorly specified, and have limited proof of concept, but tick whatever buzzword boxes are relevant to the immediate climate.

If you want to take a real stand, invest yourself in "dead" technologies. Then you can choose whatever you want, and if other people want to follow you on it it's implicit that they are working on a similar problem, and not trying to play the platforms game(else they would be looking for an angle to "modernize")

Healthy skepticism is necessary for any technologist. However, you do have to use it in both directions. I know my biases are that I prefer new technology to old. So I pay attention to that. However, it is just as bad to reflexively consign something as premature or ill-considered. Sometimes the collective hegemony gets it right. They may have missed on microservices but they didn't miss on the cloud really. I do try to be eclectic in my technology choices if only for cognitive reasons.

I'm actually very happy they chose to break this particular behaviour, based on their explanations about security and not allowing long-running services to hog up a machine when its user isn't logged in.

This is severe scope creep for an init replacement. I don't exactly know what "the service manager of the calling user" is meant to actually do (that's way the hell outside POSIX), but if a user wants one they should be able to choose, and it shouldn't matter to them how the sysadmin chose to create routing tables and mount filesystems.

Why should I be forced to prepend all of that to every command I want to survive terminal hang ups? The old mechanism was more user friendly, and better documented.

It’s just another example of systemd making everything on the system worse.

You could alias the command. You distro could do it for you. Or your ops person could. There are plenty of points where this could have happened.