u34@net9.ml wrote:

David Rosenstrauch wrote:

...

Anyone know what happened to the "telinit" shortcut? It used to be included in systemd-sysvcompat (https://wiki.archlinux.org/index.php/Systemd#systemd-sysvcompat) but seems like it recently got removed. Was it removed upstream? (And if so, anyone know why?)

Thanks,

DR

What I know is: 1. Qouting systemd(1)

For compatibility with SysV, if the binary is called as init and is not the first process on the machine (PID is not 1), it will execute telinit and pass all command line arguments unmodified. That means init and telinit are mostly equivalent when invoked from normal login sessions. See telinit(8) for more information.

2. systemd package has a telinit manual page.

I can only speculate about the answers to your other questions.

One more comment is that the 3.8 linux kernel has a new configuration option CONFIG_DEFAULT_INIT. Is it related?

On August 17, 2020 2:53:10 AM UTC, mick howe via arch-general wrote:

ArchLinux devs found a much more convoluted, obfuscated method of starting the system and setting it up "read to use". Goes with unreadable logs, etc

I think you mean systemd here, I think the only thing arch linux devs did was choose to use systemd rather than whatever they used before. These arguments are usually used targeted at systemd to explain why one dislikes it.

Am 16.08.20 um 20:59 schrieb David Rosenstrauch:

On 2020-08-15 2:53 pm, David Rosenstrauch wrote:

...

Anyone know what happened to the "telinit" shortcut?  It used to be included in systemd-sysvcompat [...]

I looked into this a bit more, and it looks like this was not an upstream change.  Rather, it was removed in Arch in this commit: https://github.com/archlinux/svntogit-packages/commit/9ca7c019fe8f59505cf1f6...

I believe it was removed as a result of upstream moving the creation of those symlinks behind the HAVE_SYSV_COMPAT flag. https://github.com/systemd/systemd/commit/6589a56972d9afe9d860889f11cb9c8e6c...

On 8/16/20 2:59 PM, David Rosenstrauch wrote:

On 2020-08-15 2:53 pm, David Rosenstrauch wrote:

...

Anyone know what happened to the "telinit" shortcut?  It used to be included in systemd-sysvcompat (https://wiki.archlinux.org/index.php/Systemd#systemd-sysvcompat) but seems like it recently got removed.  Was it removed upstream?  (And if so, anyone know why?)

I looked into this a bit more, and it looks like this was not an upstream change.  Rather, it was removed in Arch in this commit: https://github.com/archlinux/svntogit-packages/commit/9ca7c019fe8f59505cf1f6...

@eworm:   Any explanation as to why this was removed?

Reread the Arch commit. It wasn't removed. Arch used to move the symlink from the "systemd" package to the "systemd-sysvcompat" package, and no longer does so. Whether the move is done via mv && mv, or via rm && install, is immaterial. The point of the rm && install is to emulate upstream's install layout, but have parts of it in one package and parts in another package. As Andreas Bosch pointed out, the upstream install layout no longer includes these, and thus, arch doesn't move them into another package. -- Eli Schwartz Bug Wrangler and Trusted User

On 8/16/20 3:24 PM, David Rosenstrauch wrote:

On 2020-08-16 3:20 pm, Eli Schwartz via arch-general wrote:

...

Reread the Arch commit. It wasn't removed.

Arch used to move the symlink from the "systemd" package to the "systemd-sysvcompat" package, and no longer does so.

Not sure I understand.  Shouldn't it still?  (And wouldn't it be deviating from upstream if it didn't?)

Once again, reread the Arch commit. The telinit binary is no longer deleted from the "systemd" package. The telinit binary is ALSO no longer added to the "systemd-sysvcompat" package. There are only two possible conclusions: - the telinit binary is currently provided by Arch's "systemd" package and is thus available on your computer *right now*. - upstream removed it, not Arch How to determine which one is correct? Well, if you didn't snip out and completely ignore half my email, you might have seen this:

Whether the move is done via mv && mv, or via rm && install, is immaterial.

The point of the rm && install is to emulate upstream's install layout, but have parts of it in one package and parts in another package.

Most importantly, though, was this:

As Andreas Bosch pointed out, the upstream install layout no longer includes these, and thus, arch doesn't move them into another package.

However, if you didn't read my email then, I'm not sure why you'd bother reading my second email now. So perhaps I'm just wasting my time. -- Eli Schwartz Bug Wrangler and Trusted User

On 8/16/20 9:30 PM, David Rosenstrauch wrote:

There's no need to be rude.  I didn't ignore your email, and I snipped it from my response for brevity's sake to spare the list from unnecessary sprawl.

There is no ambiguity here. You suggested that this change causes Arch to deviate from upstream. The part you snipped explained how it does not, in fact, deviate from upstream. A couple of lines isn't huge sprawl. But I wouldn't care if you quoted it or not, as long as your response made it likely you read and internalized it... But, you went from me saying this (snipped) "the upstream install layout no longer includes these" [telinit cmd/man] to you responding with "Shouldn't it [arch] still? (And wouldn't it be deviating from upstream if it didn't [provide telinit]?)"

But near as I can tell, what you wrote isn't entirely accurate.  It's not that upstream no longer includes them; it's that it no longer includes them *by default*.  So rather than the package always building the telinit and runlevel binaries, it looks like it now *optionally* builds them depending on whether the HAVE_SYSV_COMPAT flag is set (to indicate whether you want to include sysv compatibility or not).

But since the package in question is called "systemd-sysvcompat" and is intended to provide "sysvinit compat for systemd", it's puzzling to me why Arch would choose to explicitly *not* set that flag when building that package.  The telinit and runlevel commands were part of the Linux sysv init system for ages, so I'm not clear what would be the point of suddenly removing them from a package whose whole intent is to provide sysvinit compatibility.  I mean, if someone doesn't need or want sysvinit compatibility, then they just wouldn't install that package altogether.  And if they did install it, then presumably they'd expect those two utilities (whose build is explicitly triggered by a flag indicating whether systemv compatibility is desired) to be included.

The preprocessor macro HAVE_SYSV_COMPAT does a *lot* more than provide some symlinks. The sysvcompat symlinks still installed are: - halt - reboot - poweroff - shutdown - init These programs are generically useful on fully systemd systems, and systemd documents them as such: "These commands are implemented in a way that preserves basic compatibility with the original SysV commands. systemctl(1) verbs halt, poweroff, reboot provide the same functionality with some additional features." When it comes to telinit, the description is, rather: "This is a legacy command available for compatibility only. It should not be used anymore, as the concept of runlevels is obsolete." It seems clear to me why it's no longer installed except when systemd is configured with the necessary code to interpret and convert old /etc/init.d and /etc/rc.d infrastructure into stubbed systemd units. As for whether systemd should provide a split sysvcompat package that provides symlinks for generally useful programs styled after sysvinit, or, alternatively, provide the full-blown HAVE_SYSV_COMPAT initscript parser etc? Personally, I don't believe the split is useful anymore, as I believe it was originally meant for the sysvinit -> systemd migration period to allow having both installed at the same time and easily switching between the two. I'd rather remove it entirely, and fold it into "systemd". It's required by "base" anyway, lol. I don't believe the intention is to provide runtime generation of systemd units, and I think the pkgdesc is misleadingly simple in that regard. ... Anyway, if you want to have dialogue about whether it's useful to have a telinit program, regardless of upstream's defaults, by all means, feel free to have that discussion. But can it please not include rationalizations like "why are we deviating from upstream by not including it"? -- Eli Schwartz Bug Wrangler and Trusted User

Em agosto 17, 2020 12:56 David Rosenstrauch escreveu:

Hmmm ... OK. I wasn't aware that telinit was now being considered legacy/deprecated. I've habitually used it for years to drop to single user mode, which I do every time before I perform a system update with pacman. I guess I'll have to find some other command to do the same using systemd. (I think they call it rescue mode, rather than single user mode.)

Thanks,

systemctl rescue But this begs the question, why are you doing this before running pacman? Regards, Giancarlo Razzolini

Em agosto 17, 2020 13:08 David Rosenstrauch escreveu:

??? I always shut down all running daemons when I'm about to update my system - seems like standard operating procedure to me: 1) I'd expect that it would be completely unpredictable what would happen if you updated/replaced an application's files while it was running, 2) there's often config file changes that occur; again, I don't want to try to update or resolve those while an application is running.

It's not necessary to do so in most cases, but, you might be interested in checkservices [0]. We use it when we update Arch servers, but we don't bring the system to rescue because, you know, that would interrupt all the services. And almost all of them (all?), can run just fine until they are restarted. So, my suggestion to you is, run pacman, and optionally run checkservices afterwards, to restart things that might be needed, if you want. No need to put the system in rescue mode. Regards, Giancarlo Razzolini [0] https://github.com/archlinux/contrib/blob/master/admin/checkservices

Op ma 17 aug. 2020 18:08 schreef David Rosenstrauch :

On 8/17/20 12:01 PM, Giancarlo Razzolini via arch-general wrote:

...

systemctl rescue

Thanks!

...

But this begs the question, why are you doing this before running pacman?

??? I always shut down all running daemons when I'm about to update my system - seems like standard operating procedure to me:

For (older) Windows systems: yes, something like this was sometimes neccesary. Unix behaves different: 1) I'd expect

that it would be completely unpredictable what would happen if you updated/replaced an application's files while it was running,

Actually, not much. When $process has a file open and that file gets deleted or replaced, $process can hapily continue using the old data. Until it reopens the file (data or application code), it'll keep using the old version. 2) there's

often config file changes that occur; again, I don't want to try to update or resolve those while an application is running.

Same as #1: config files are usually read when starting and ignored while running. That said, it's still a good idea to restart the running services (or the whole server when the kernel is updated), but in principle you can just continue working while updating and reboot sometime later. Mvg, Guus Snijders

David Rosenstrauch on Sun, 2020/08/16 14:59:

On 2020-08-15 2:53 pm, David Rosenstrauch wrote:

...

Anyone know what happened to the "telinit" shortcut? It used to be included in systemd-sysvcompat (https://wiki.archlinux.org/index.php/Systemd#systemd-sysvcompat) but seems like it recently got removed. Was it removed upstream? (And if so, anyone know why?)

I looked into this a bit more, and it looks like this was not an upstream change. Rather, it was removed in Arch in this commit: https://github.com/archlinux/svntogit-packages/commit/9ca7c019fe8f59505cf1f6...

@eworm: Any explanation as to why this was removed?

Upstream does no longer install it by default. https://github.com/systemd/systemd/commit/6589a56972d9afe9d860889f11cb9c8e6c... Do we still need it? -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}