-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FAIL: 38: can not parse arg #1 #907
Comments
Hi fradaxx,
As you found in the other issue the -e switch works for me too and I think that should be the preferred way. On my box if I run a Would running telegram-cli in daemon mode be an option for you? HTH, |
Hi BeMoD, thanks for your answer! I just tried your first solution and, incredibly, it works also in my case!! The second solution doesn't work for me; I implemented it using the following bash script (I'm not sure about its correctness due to my limited experience with Linux...) #!/bin/bash I observe the pause of about 3 secs but the message is not sent at all. And finally: yes, using Telegram-cli in daemon mode would be an optimum solution for me but... now I don't know how to do it! I know that Telegram-cli has the -d switch to daemonize it but I don't know exactly how to use it. Thank you again for your answer! Regards. Francesco |
Hi Francesco, good to hear that the sleep works for you too. But regarding your script, there are some problems. This one will work:
Second: There is no need to use eval. You can just use the line
inside your script. Now the daemon thing: The final step would be to configure ubuntu to autostart and stop the daemon on system boot and halt. To do this run HTH, |
Hi beMoD, thanks again for your hits! I just tried the first solution (the one with the -e option) and, of course, now it works well! Now I am trying the daemon way; I already created the script, made it executable and run it as service. It starts but, for now, it refuses the connection when I issue the command echo "msg hi_ho hi hi ho" | nc -q 1 localhost $TGPORT However it is only matter of time; I will discover soon what's wrong in my case! Francesco |
You notice you have to replace $TGPORT with the port configured in the init script right? |
Oh yes, of course I done this substitution, but it doesn't work anyway... |
What does the logfile show? |
If I set USERNAME/GROUPNAME with the regular user/group (ubuntu/ubuntu), the log file is not created at all, I guess for permissions problems. If I set them as root/root the logfile is created and when I issue the command "echo....", the following lines are added to it: Telegram-cli version 1.3.3, Copyright (C) 2013-2015 Vitaly Valtman So the problem is with the script tg-handler.lua which is not found; I don't know where it is in my system (I'm trying to find it). I built telegram in /home/ubuntu/tg |
Yes, its a permission issue, as only root can write to /var/log by default. You can create the logfile once manually and chown it to the correct user. tg-handler.lua is a script I wrote myself. It handles incoming messages. You can just remove |
I removed the "-s $ReceiveLua" portion, saved and restarted the service; it "seems" to work only for the first time, but indeed the message is not sent/received and, from the second command issue on, it returns the "FAIL: 38:" error... I think that I need to do many experiments with my specific case. However, for now, it is sufficient to have the first method working; I will continue to make tries by myself on the daemon (I cannot continue to take advantage of your kindness...). Thanks again for all your help! |
I'd be glad to help and it should not be a big deal to get your setup running in daemon mode so let me know if you need any further assistance. But if you want to try on your own im fine with that too :-) |
beMoD, thank you again for your kindness! Francesco |
Hi beMoD, sorry to disturb you again but... I am unable to solve the daemon problems by myself as I hoped... so I am in need of your help again! This is the script I use: This is what if is added in the log file everytime I reboot my system and/or I restart the telegram-cli service: Telegram-cli version 1.3.3, Copyright (C) 2013-2015 Vitaly Valtman When telegram-cli receives an incoming message, these lines are added to the log file: [warn] Epoll ADD(1) on fd 0 failed. Old events were 0; read change was 1 (add); write change was 0 (none): Operation not permitted Script receive_handler.lua should do only a echo of the received messages but it doesn't: If I issue the command echo "msg contact_name Hello World" | nc -q 1 localhost 1234 I always obtain: ANSWER 31 on the prompt, and these lines are added to the log file: *** Accepting incoming connection Please, can you help me to find where the problem is? |
There is no real error message in the log besides the FAIL 38. A short google search for the warn message implies that it can be ignored, though im not completly sure. For FAIL 38: Try |
Hi beMoD! Thanks for your answer! here are the results of my experiments following your hints: If I issue the command echo "contact_list" | nc -q 1 localhost 1234 Nothing appears on the prompt but these lines are added to log file: *** Accepting incoming connection If I try to add (or re-add, because I am sure it already exists) the contact with a command like echo "add_contact +39xxxxxxxxx name surname" | nc -q 1 localhost 1234 these lines are added to log file: *** Accepting incoming connection It seems to be some authentication problem, but I am unable to identify it Francesco |
Hey, yes, seems you are not registered with telegram service. Stop the daemon. Then please remove /root/.telegram-cli and start telegram-cli without the startscript and without the -d option as root: Then enter your phone number to authorize yourself again using the normal command prompt. After that contact_list should show you your contacts. Then you can safe_quit the client and start the daemon again. Then But please note: I would really really really not suggest to run telegram-cli as root. For testing purposes you can do this, but I would not advise running any services as root when user rights are sufficient. There could be bugs in it which could allow a remote user to get root access to your machine. The better way would be to create a special user that is only used to run telegram-cli. |
Hi beMoD, in my opinion the problem is not related to the registration with the Telegram service because I can use Telegram-cli from command line. I removed the autostart script from /etc/init.d and made some other tries on my own launching this bash script at startup using crontab (telegramd is a dedicated user I created to securely use Telegram-cli, as you suggested): #!/bin/bash TGPATH=/home/ubuntu/tg The line added to my crontab config file is: @reboot nohup sh /home/ubuntu/run_telegram & (run_telegram is the script name I saved in /home/ubuntu) With this script I have Telegram-cli permanently online and thanks to receive_handler.lua it echoes every text message I send using my other Telegram account on smartphone/tablet/PC. However it doesn't execute any command that I send to it using the command echo | nc -q 1 localhost 1234 At every command the following lines are added to the log file: *** Accepting incoming connection but nothing else happens; if I request the contact list it is not printed out, if I try to send a message with echo "msg Name_Surname This is a try message" | nc -q 1 localhost 1234 it is apparently sent because I read this in the logfile: *** Accepting incoming connection but nothing is received on the remote Telegram account (activated on my smartphone, tablet and PC), nonetheless Name Surname is correctly listed in the contact list of Telegram-cli) Do you see any problem/error in the command I use to launch Telegram-cli; is there some more detailed log level I can activate to see in more detail what happens when I send a command using netcat? Thanks in advance for any hint! |
Hi, your setup is a bit mixed up I think. The sending message problem is not related to that, but let me explain why your setup is mixed up. You say you created a crontab entry and I believe you created it as user "ubuntu". The crontab of the user ubuntu is run by the user ubuntu so the telegram process is only running with user rights. Now you have specified the -U and -G options on the commandline, but the process is not able to switch the context to the user telegramd, because it is only running with user rights. So telegram-cli is still running as user ubuntu (you can see by issuing When using the init script, which is run by root, the process is able to switch the context to the user telegramd (again look at the process using The solution would be, as described in my last message: su to the user telegramd (root in my last message) run the client in command line mode and auth it. Then the init script will work and telegram-cli is running in the correct user context. Regarding your sending problem I currently have no idea what could be the problem because the log states, that everything is working.
This part shows, that a connection to the port (using the nc command) is opened, then it reads your "echo" and then closes the connection again.
|
I had this problem too, solved by send command dialog_list first, then follow by msg my script is going like this |
Was facing this issue as well. And as said by @fredkard adding a dialog_list before a msg worked. I think the issue is that tg doesn't store the user id somewhere? |
this works... seems odd that I have to run the contacts_list command before the msg command will work though. |
Big oof. Someone is still using this? The repository has not been updated for years and I stopped using it because of evil memory holes I encountered that killed my Pi every few days :-/ |
I suspect you'll only encounter memory issues if you run it in daemon mode (or constantly)... whereas running it like I'm talking about (i.e. just to send one message) is probably memory safe. |
Hi,
I re-submit this already known issue because it seems that it is recurrent and, unfortunately, none of the already proposed solutions work, at least in my case.
I downloaded the Telegram-cli sources and successfully built them on my UDOO-quad (an Ubuntu 12.04-based SBC, www.udoo.org); if I try to send a message "manually", putting the "msg" command on the Telegram prompt it works properly. Also it receives messages from remote and all other commands seem to work correctly.
If I try to automate the message send process using this bash script:
!/bin/bash
to=$1
msg=$2
tgpath=/home/ubuntu/tg
cd ${tgpath}
(echo "msg $to $msg"; echo "safe_quit") | bin/telegram-cli -W -v -k server.pub
it returns always the "FAIL: 38: can not parse arg #1" error; this is a transcript of what I obtain when I call the shell script containing the previous commands:
Telegram-cli version 1.3.3, Copyright (C) 2013-2015 Vitaly Valtman
Telegram-cli comes with ABSOLUTELY NO WARRANTY; for details type
show_license'. This is free software, and you are welcome to redistribute it under certain conditions; type
show_license' for details.Telegram-cli uses libtgl version 2.0.3
Telegram-cli includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)
Telegram-cli uses libpython version 2.7.3
I: config dir=[/home/ubuntu/.telegram-cli]
*** adjusting CLOCK_MONOTONIC delta to 0.242843
*** adjusting CLOCK_MONOTONIC delta to 0.249272
*** adjusting CLOCK_MONOTONIC delta to 0.559830
*** adjusting CLOCK_MONOTONIC delta to 0.556163
*** adjusting CLOCK_MONOTONIC delta to 0.256063
Please note that I added the -v switch to increase the level of verbosity in the hope to have some more info about the cause of the error; it seems that the problem is related to the contact list load process (-W switch), that seems to be asynchronous and too slow, nonetheless in my case it is made of only 2 contacts.
I also tried to add a "sleep" of several seconds before the first echo command on the last line, to give more time to the contact list addresses to load:
(sleep 5s; echo "msg $to $msg"; echo "safe_quit") | bin/telegram-cli -W -v -k server.pub
but the result doesn't change.
I observed that if I add the "contact_list" command in front of the echo commands, followed by the sleep bash command, the list of contacts always appear only AFTER the issue of the "safe_quit" command, and this makes me suspect that the contact list load process is very slow and asynchronous (also that started automatically thanks to the -W switch) and it doesn't last before the issue of the msg command.
I also tried to use the -e switch in the telegram-cli call (as suggested in another similar issue) but the behaviour doens't change at all.
This problem greatly limits the possibility of use of telegram-cli on my case, because I need to use my SBC as a home automation gateway, using telegram as a input/output message layer.
Please, can I ask if there is there any hint/official script to definitely solve this issue?
Thanks in advance for the answer.
Francesco - Italy
The text was updated successfully, but these errors were encountered: