Debian Pains, Ping Pong support

[zimbodel]

Solved: Using following link. Seemingly a Debian Bug.
"https://www.nixcraft.com/t/solved-cron-reboot-wont-work-on-debian-linux/1858"

Original messgae
-----------------------------------------------------------------------------------------------------
The last few debian versions started ping-ponging with very serious basic services that I relied on for decade+

1) It seems that control Alt F1-9 is now abolished.
All of them I cant even get one terminal.
Sheesh !!! now if I have an X problem and get a hung login screen I cant even control+alt+F1 to a terminal and quickly fix the mess. I guess now I have to boot into rescue mode and have no realtime problem resolution anymore.
This is really braindead not to support this anymore. In stretch it is not working and neither did it on some previous Debian versions during vanilla install.
Really painful...it is like silently abolishing Cron (which would be irresponsible).
Are you guys going to abolish it now finally or what is the plan ?

2) rc.local doesnt work anymore although it is included in /etc. It has been pingponging working/notworking between distributions.
The previous distribution started to leave out chmod +x on default which made it not execute. Even that now doesnt help anymore.
Are you guys going to at least have an executable rc.local in future versions or does boring but brick-stable BSD become more attractive to me again.

3) There is also on/off support for @reboot in cron.
I write cron scripts and then they dont work when upgrading to a newer debion version.
Why the backwards compatibilty issues with such a mission critical application?
Are you guys going to abolish it now finally or what is the plan ? as I now have to keep different scripts for different Debian versions.

[Head_on_a_Stick]

It seems that control Alt F1-9 is now abolished

Nope, works fine for me.

If you're using `startx` from a console login then you may be running X on tty1 (I am) so try <Ctrl>+<Alt>+F2 instead.

rc.local doesnt work anymore

Code: Select all

# systemctl enable rc-local.service

Perhaps?

Or just learn to write unit files, they are *much* easier than init scripts and they don't rely on buggy, bloated bash, which is nice.

There is also on/off support for @reboot in cron.
I write cron scripts and then they dont work when upgrading to a newer debion version.
Why the backwards compatibilty issues with such a mission critical application?

Pass on this one, I prefer systemd .timer units

[zimbodel]

" Head_on_a_Stick wrote
Nope, works fine for me.
If you're using `startx` from a console login then you may be running X on tty1 (I am) so try <Ctrl>+<Alt>+F2 instead.
"
None of F1-9 works.
Read my initial post.

" Head_on_a_Stick wrote
Or just learn to write unit files, they are *much* easier than init scripts and they don't rely on buggy, bloated bash, which is nice."

Not acceptable. If rc.local is present in /etc in the distribution then it should be usable else it is misleading the user.
If it is not supported anymore, remove it.

[Head_on_a_Stick]

None of F1-9 works.

Can we please see

Code: Select all

systemctl status getty@tty2.service --no-p

Thanks!

[dilberts_left_nut]

3) There is also on/off support for @reboot in cron.

This works fine for me.

What have you done to your Debian?

[bw123]

rc.local has never been a good thing. I agree get rid of it.

[Head_on_a_Stick]

Not acceptable

You do know there are no Debian developers here, right?

I know that I couldn't give a flying shit about what you consider to be acceptable, nor do I care which operating system you use

[zimbodel]

Is it also now standard on all default Debian window managers that the
Control+ALT+F1-9 keys are now just nonchalantly switching virtual desktops and not give me a single virtual terminal as it used to do for ages.
This is crucial as I run critical scripts I need to monitor in those so that they are not in the xsession

This decision makes zero sense.

[bw123]

Is it also now standard on all default Debian window managers that the
Control+ALT+F1-9 keys are now just nonchalantly switching virtual desktops and not give me a single virtual terminal as it used to do for ages.
This is crucual as I run critical scripts I need to monitor in those so that they are not in the xsession

This decision makes zero sense.

How can there be "all default Debian window managers" ? that makes no sense

Do you mean gnome removed the key combo to get to a tty? At least on fluxbox and kde plasma, the ctrl-alt+F keys still work.

[Head_on_a_Stick]

Is it also now standard on all default Debian window managers that the
Control+ALT+F1-9 keys are now just nonchalantly switching virtual desktops and not give me a single virtual terminal as it used to do for ages.

Which window manager are you using?

The switching works for me with dwm, openbox & bspwm.

[bw123]

ping? pong?

[zimbodel]

Then dont give a shit and ignore the post.

Not acceptable

You do know there are no Debian developers here, right?
I know that I couldn't give a flying shit about what you consider to be acceptable, nor do I care which operating system you use

As to your reequeest.
$ sudo systemctl status getty@tty2.service --no-p
Failed to get properties: No such interface ''

[zimbodel]

That is fine, but if it is included in the distro it must work, not be abolished and ping pong working on and off with every other debian distribution.

rc.local has never been a good thing. I agree get rid of it.

[Head_on_a_Stick]

$ sudo systemctl status getty@tty2.service --no-p
Failed to get properties: No such interface ''

OK, that's not normal.

How about

Code: Select all

cat /proc/1/comm

Oh, and don't run commands as root unless specifically instructed to do so, that is a dangerous habit.

[zimbodel]

$ sudo systemctl status getty@tty2.service --no-p
How about

Code: Select all

cat /proc/1/comm

Oh, and don't run commands as root unless specifically instructed to do so, that is a dangerous habit.

I will run my systems any way I want. I have been doing so for more than 20 years with no issue.
Maybe some children should not be allowed in the sandbox and needs a safe space.

So the advice really applies to you.
Enjoy your deserved safespace. (try sudo first)

To your blerp.
# cat /proc/1/comm
init

which is the wrong place to look.