E
E
EVG822021-12-26 12:46:00
Python
EVG82, 2021-12-26 12:46:00

Why is the Python version being downgraded?

From the hoster I have
a virtual environment in python 3.8
, not a VPS, so I
didn’t have enough rights
and earned a bot
session through putty

closed the session - the bot stopped working

created the session again and decided to check the python version
changed by itself from 3.8 to 2.75 to the most old from hoster

1 Hoster has a problem? Silent for now
2 Is there a problem in the current code?

import telebot

token = '5045270686:AAEOxCH'
bot = telebot.TeleBot(token)
GROUP_ID = "@buest"
inputfile = '1.txt'
f = open(inputfile, mode='r', encoding='utf-8')
blacklist = list(map(str.strip, f.readlines()))

@bot.message_handler(content_types=["text"])
def handle_text(message):
    for x in blacklist:
        if (x in message.text):
            bot.delete_message(message.chat.id, message.message_id)
        else:
            pass


if __name__ == "__main__":
    bot.infinity_polling()

maybe it is sharpened under 2.7.5?

Answer the question

In order to leave comments, you need to log in

1 answer(s)
V
Vindicar, 2021-12-26
@EVG82

You need to turn your head a little and read about how SSH and the Unix shell of the system work. Googling like "SSH keep program running" would quickly lead you to the right place.
1. When you connect via SSH, the server runs a copy of bash or sh (or whatever shell you use) as your user.

<br>
sshd<br>
  - bash<br>

When you enter a command in this shell, the program is looked for in the system PATH, and the second python is located in it.
2. Then when you do activate, you go into the virtual environment. It differs in that the python is searched there by default for another one, since PATH has been changed there (and something else). And this transition occurs due to the launch of a child command shell.
<br>
sshd<br>
  - bash<br>
      - activate <br>
          - bash<br>

3. You run your script. It is run from a shell inside activate.
<br>
sshd<br>
  - bash<br>
      - activate<br>
          - bash<br>
              - python3 your_script.py<br>

4. You close putty. The SSH server logs the client disconnect, and sends a HUP signal to the child bash - this is usually interpreted as a signal to terminate. That one passes this signal to its child process, and so on.
<br>
sshd "sshd: эй, bash, завершайся"<br>
  - bash "bash: эй, activate, завершайся. А теперь я сам завершусь."<br>
      - activate "activate: эй, bash, завершайся. А теперь я сам завершусь"<br>
          - bash "bash: эй, python3, завершайся. А теперь я сам завершусь"<br>
              - python3 your_script.py "python3: хорошо, завершаюсь."<br>

As a result, we get only a working ssh server
sshd
. And when you reopen the session, activate has already ceased to exist, and you again find yourself in regular bash, where only the second python is registered in PATH.
Now the main thing: how to get around this? You need to make python3 ignore the exit signal. There are several ways.
The simplest is to use this syntax: The
nohup python3 your_script.py &
ampersand at the end means "run the program and return to the shell without waiting for the program to finish running". And the nohup command runs the specified program with the specified arguments, but it will ignore the HUP signal, i.e. "hey, end it." Therefore, when you close putty, the bot should remain running.
Minus - after reconnecting, you will not see the output of the bot to the console.
To stop the bot, you have to use ps to find out its process ID, and kill to kill this process. Well, or you can provide an exit command in the bot itself, which will terminate the script from the inside. It is more comfortable.
The second way is to use the screen program if it is installed. Googled the documentation for it. In short, screen allows you to create a virtual work session that you can connect to and disconnect from without interrupting it. In this case, all screen output is preserved between reconnections. It is convenient if the bot writes a lot to the console, but it is somewhat dreary, and you need to learn keyboard shortcuts.
The third way is to make the bot start on boot, via an init.d script or a systemd module. But since you have minimal rights, most likely it will not work.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question