Hello everyone,
I would like to run shell scripts when I power on my jetson nano. I tried many things like rc local, setup a service, crontab etc…
Maybe a login issue? Idk…
Nothing seems to work, if anyone has a good solution, I would be really happy to read it!
Hi @Airodtech-Toulouse ,
We have discussed about running scripts when power on. I hope this topic could solve your problem.
Hi hard workers I’m writing to you because I still can’t properly run the automatic startup of my program during the reboot .
Indeed I have tried three different methods of integration and nothing works knowing that I can only do it through the terminal
1st method use the method crontab: fail
2nd method: use uptate-rc. d: fail
3rd method: use systemctl: half walk
4th method: use startupinstall linux: impossible to launch on graphical mode
As a reminder, the system runs under the following configuration :
Board: Jetson TX2 model 945-82771-0005-000 AU (P/N: 699-82597-0000-900 E)
OS: Ubuntu 18.04.5 LTS tegra version
Available below :
Télécharger l’image de la Carte Jetson Nano (lien )
(https://developer.nvidia.com/embedded/downloads#?search=NVIDIA%20SDK%20Manager).
Details of my problem:
Currently the program doesn’t launch correctly and python scripts don’t launch also,i don’t have access data to the GPIO port during reboot and auto-launch.
A code error problem is to be prescribed because when manually launching in the directory « /home/airoddev/projects/SW/ » folder of my program by the classic « . /a.out » no problems are reported, the programs wait well for the data coming from the plc and the two scripts are correctly launched coming from python3 and python3.7 or image 1 for a classic behavior when launching manually.
The a.out and python and python 3.7 process are working as intended, and can be seen by terminal command Htop and ps-all SEE image n°1
As the post in the startup request topic, I created a file named Script_demarrage.service in the directories /lib/systemd/system and having the following rights -rwxr-xr-x 1 root:root
The file contains :
[Unit]
After=network.target
Description=“Lancement machine”
[Service]
ExecStart=/bin/bash /home/airoddev/projects/SW/Script_demarrage.sh
User=airoddev
[Install]
WantedBy=multi-user.target
The sh startup script nammed « Script_demarrage.sh » file contains an ultra-simple script present below.
#!/bin/bash
BEGIN INIT INFO
Provides: aizac florian
Default-Start: 2 3 4 5
Default-Stop: 0 1 6
Short-Description: description du programme
Lancement du programme
END INIT INFO
le nom du service
SERVICE_NAME=Lancement_machine
le répertoire où se trouvent les exécutables du service
SERVICE_DIRECTORY=~/projects/SW_embarque_sexage
le nom du script de démarrage du service
SERVICE_STARTUP_SCRIPT=“a.out”
le nom du script d’arrêt du service
echo $(pwd)
echo “Lancement machine”
echo "Attente… "
sleep 10
echo "Fin du wait Lancement machine "
cd ~/projects/SW /
./a.out
Having the following rights -rwxrwxrwx 1 airoddev airoddev Script_demarrage.sh in directories projects/SW
When ordering « sudo systemctl status Script_demarrage.service » the result of the status give me a good response and the service is active and should be functional but in fact it does not launch both python scripts and I have no access to the GPIO, even a classic LED switch when restarting does not work! then when using directly a command to move in the folder and starts the program in manual (./a.out) it works.
As you can see here in photo #3 the program starts at the reboot but one of the pythons doesn’t start and I can not even switch the state of my default LED because the GPIO ports are inactive.
Could you direct me to a solution that might allow me to solve my problem? or tell me where was my mistake? By thanking you for having taken the time to read me.
I wish you a pleasant and good day.
Cordialy Étienne
Script_demarrage.sh (709 Bytes)
The “/lib” system directories should not be used for this unless you are installing with a proper package. Custom content should be added in “/etc/systemd/system/”, perhaps as a sym link to “/usr/local/lib/systemd/system/”. This won’t change if it works or not, but customization was not intended for the “/lib/systemd/” content. Overall though, the use of systemd to start things is likely the recommended method of script start if it isn’t dependent upon a specific user being logged in to the GUI.
I’ll provide an example which runs as a one shot and creates a file in “/tmp” to verify if it ran.
In “/usr/local/bin”, file “hello.sh”:
#!/bin/bash
/bin/echo "Hello world, systemd version!";
/usr/bin/wall "Hello to everyone!" 2>/dev/null;
/bin/echo "Hello tmp" > '/tmp/hello.txt';
/bin/date >> '/tmp/hello.txt';
Note that the “wall” code just echos to all terminals, but it would indicate an error if there are no terminals open, so it redirects errors to “/dev/null”. If you run a command to start hello.service manually, then wall will echo its hello line to all users. The file “/tmp/hello.txt” will contain a timestamp, and so you can “cat /tmp/hello.txt” and verify the timestamp is for that boot.
If you run “hello.sh” as one user, and then switch to another user without that new user being root, then you’ll need to first manually delete “/tmp/hello.txt” since one user cannot overwrite another user’s file (unless it is root doing the overwrite).
The file “hello.service” has this content:
[Unit]
Description=Hello world demo
Requires=multi-user.target
After=network.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/hello.sh -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
User=ubuntu
[Install]
Alias=hello.service
Note: I don’t know why it adds the $SSHD_OPTS, but disable and enable of the service adds this into the file…it wasn’t me adding that. I probably did something odd, but it doesn’t matter for the demo. The service file itself could be added here:
sudo -s
mkdir -p /usr/local/lib/systemd/system
cd /usr/local/lib/systemd/system
touch hello.service
# Use vi or whatever editor you use, and create the content of hello.service
exit
Also note that I have “Type=oneshot”, but you might need another type since your program is going to keep running. For example, it might be “Type=exec” or “Type=simple”.
Then you should be able to:
sudo -s
cd /etc/systemd/system
ln -s /usr/local/lib/systemd/system/hello.service .
systemctl enable hello.service
# Or "systemctl disable hello.service"
exit
Each time you enable or disable hello.service the symbolic link in “/etc/systemd/system/hello.service” should do the correct thing.
Each time you reboot you should be able “cat /tmp/hello.txt” and see a timestamp in it corresponding to the moment multi-user.target is reached. If you run command “ls -l /tmp/hello.txt”, then you can confirm it is owned by user “ubuntu”. Very important: If you want to use a different user, e.g., “airoddev”, then name that user in the hello.service file instead of “ubuntu”.
You can then adapt your service that way. Keep in mind that if your program uses the GPU, then the user should be a member of group “video”. Since this works for you on manual start this is known to be correct already, but other users might see this and need to know about group “video”.
If your program uses CUDA or the GPU without its own code to make it possible to use without a GUI, then it might also require a valid DISPLAY environment which points to an X session run by the given user. This would imply needing graphical.target instead of multi-user.target. This would also require waiting for that user to start an actual X session before attempting the GPU-based program. I don’t know what your program’s requirements are, but the template above should do the job for simple cases.
Hello, thank you for responding so quickly.
The problem persists after completing your procedure.
I wonder if it exists in service file
[Unit]
Requires=multi-user.target
After=network.target
a way to launch it only by the user and after loading all these libraries, because currently this way I still don’t have access to the GPIO port as well as some Python library.
Cordialy Etienne
What user do you normally run this program as? What is the full path of the executable? For the sake of illustration I will pretend your user name is “ubuntu”, and that the full path is “/home/ubuntu/a.out” (a bad location which should instead be somewhere like “/usr/local/bin”, but that’s another story). If you are logged in as root, e.g., you’ve run command “sudo -s”, then root won’t need a password to run a.out using sudo as user ubuntu. It could go something like this (full paths used since scripts are best written with full paths):
/usr/bin/sudo -u ubuntu /home/ubuntu/a.out
When the system is booting and running startup it runs as root. Thus the command above, if run by the operating system startup scripts, would run a.out as user ubuntu.
Do you have a local terminal on the Jetson? If so, then you can get to a purely text-based terminal via something like CTRL-ALT-F3, and back to the GUI with ALT-F1 (btw, “F1” corresponds to the “DISPLAY” environment variable as “:1” if and only if the X server is running on F1; in some cases it might run on ALT-F2 might be where the X GUI server lives, and then DISPLAY would be “:2”). Any terminal you open from the X GUI environment inherits DISPLAY, but we want to test in a terminal which has NO DISPLAY. If your command worked from a GUI it isn’t much of a test, so switch to a purely text-based terminal, verify there is no response from “echo $DISPLAY”, and then run your command there to see if it works:
CTRL-ALT-F3
sudo -s
/usr/bin/sudo -u ubuntu /home/ubuntu/a.out
# Then exit when done:
exit
ALT-F1
Does the application complain about something related to X or DISPLAY? Then this means you must associate running your application from a GUI and not run it without a GUI. If it runs like this, then the startup script should work, and failing has some other cause. Most GPU applications require the GUI (not necessarily for graphics, but instead for GPU access).
Note: If you don’t have a local monitor/keyboard, then you can use “ssh” to connect, but do not use the “-X” or “-Y” options for forwarding.
Hello, thank you for your reply.
The user who should run the exe is the user airoddev.
the user’s full path is:“/home/airoddev/projects/SW_embarque_sexage” the exe in this folder that I want to run on auto-start is in this file « ./a out » and MUST was run by airoddev as shown in the photos above.
I only have access to the terminal no possibility to use the graphical GUI.
In addition to this I cannot use a keyboard directly connect to the card, I connect to the card via SSH and modify and access on the card via PUTTY.
In addition I have another problem I do not currently manage that the user logs automatically to the machine he must always enter his password which is impossible for future use.
the final behavior I’m looking for: The cards will have to automatically connect to the user airoddev without entering the password and then start the program “a out” automatically when the card is switched on.
That won’t be an issue. In fact, since this does not forward an X server (Windows does not have an X server unless you operate in an environment like Cygwin or may WSL), if you can show your application can launch from that ssh session, then we know the GPU access is not a problem. If you log in manually to user airoddev, can you successfully start your application on command line? If so, then this demonstrates your case is simpler than most.
If the above is correct where no GUI is needed and ordinary ssh login can start the app, then a script line which prefixes the startup command with this should work:
/usr/bin/sudo -u aeroddev /home/airoddev/projects/SW_embarque_sexage/a.out
The key to this is that since root runs the init scripts, then the sudo won’t ask for a password…root does not require a password. There is a possibility that if some form of security limited shell is involved you might need to use that shell in the script. Have you tried the systemd scripting mentioned above, but with the actual a.out example as the starting command?
Hi ,
my problem is still not solved and I don’t understand why it doesn’t work.
I installed an overlay “apt install gnome-startup-applications.”
How to Manage Startup Programs on Ubuntu Linux (howtogeek.com)
Here is the video below describing exactly the problem
Since I don’t know anything about the hardware or setup in the video, here are some questions:
- Is the terminal you are typing into and have the monitor set up on from a Jetson TX2 dev kit?
- Among the L.E.D.s on the rack mounted hardware, are these controlled on the same Jetson, or perhaps instead from some sort of signal the Jetson sends to other devices? Are the other devices Jetsons?
- I see one L.E.D. which is not blinking from the auto login program running, but is blinking when you run
a.outmanually. Is this the only L.E.D. in question? Is the L.E.D. controlled via GPIO, or from some other method? - Note that if GPIO is used, and something is still setting up GPIO at the time of auto login, then this might account for failing (however, I see the “
sleep 10” which should probably get around that if it is the case). - Note that if ethernet is used for communicating to another system for the L.E.D., then networking must be set up; if WiFi is involved, then GUI login changes how to make this work, but if wired ethernet is already set up, then this won’t be an issue. It is important to know how the program communicates with outside systems if the L.E.D. in question is not connected to the local system.
- Tip: “
who” shows who is logged in, but does not say who is running the script (not definitively). The system runs various processes from non-login processes. You should replace “who” with:
echo "Session Owner: $(whoami)"
echo "DISPLAY: $DISPLAY`"
# Or, combined:
echo "Session Owner: $(whoami), login from DISPLAY $DISPLAY"
- During boot I see device
loop0is aFAT-fsfilesystem which was improperly unmounted. Is there any relation for betweenloop0and successful running of the program? They might be completely unrelated, but I don’t know anything about your setup.
I am just going through what I see more or less in the order I see it, so what follows is not necessarily anything more than small facts I discover as I go through the video.
You are using gnome (gnome-terminal) to start the program, so none of this will ever work without first logging in to a GUI. This means you are not interested in running the a.out on startup, but instead are interested in running a.out when the user logs in to a gnome GUI. It seems you have auto login set, so that is not a problem and a GUI login becomes synonymous with startup; you know login will always occur immediately and without any user intervention required. This logic is valid since this is equivalent to “on startup”.
It is important to note that running the app via gnome-terminal in this fashion implies inheriting the “DISPLAY” environment variable (see “echo $DISPLAY”) from the existing GUI. If there is no existing GUI, then there is no “DISPLAY”, and the program must fail. In theory, if you auto log in to gnome and then the a.out runs, then the logic is valid and equivalent to manually setting up a DISPLAY.
The part where the script first performs an echo suggests “echo $DISPLAY” returns “:0”. This is valid and not an issue, but see the original notes about this at the top of the post…one needs to “whoami” instead of “who” if you are to be certain about who the process runs as.
Your command redirects stdout and stderr to “/dev/null”. It might be interesting (at least for the auto login case) to instead redirect stderr to a log file. Perhaps it will mention something not seen when running a.out from an existing login. If toggle of the L.E.D. is due to certain errors, then stderr might show something for this case (assuming you give permission to create files wherever a stderr redirect goes).
It looks very much like any error you might detect would be from the a.out application itself. It also seems that any such error is likely something inherited from the environment and not necessarily an issue with a.out itself. Would it be possible to expand more on the topic of how a.out is communicating, and if there is some block of code limited to just this subset of a.out which you can post? Would it be possible to see any stderr output which a.out might produce when running via auto login?
I will try to answer your questions as best I can.
- Is the terminal you are typing into and have the monitor set up on from a Jetson TX2 dev kit? :Of course yes, the only recent change was to add “apt install gnome-startup-applications” to the existing OS to have access to the startup application because the startup launch updater, cron or systemctl on YOUR OS probably doesn’t work due to an Nvidia overlay … (As a reminder in the future the machines will not be connected to a screen and will launch on each card the execution file “a.out” .
- Among the L.E.D.s on the rack mounted hardware, are these controlled on the same Jetson, or perhaps instead from some sort of signal the Jetson sends to other devices? Are the other devices Jetsons? : All cards are the same, the problem is the same on all cards. In manual mode no problem but when rebooting and auto-launch there is a problem. the screen is plugged in to show you that it works when I run the program manually otherwise eventually it will not be plugged in any screen.
- Note that if GPIO is used, and something is still setting up GPIO at the time of auto login, then this might account for failing (however, I see the “” which should probably get around that if it is the case).
sleep 10: The problem is that when auto-launch my GPIO ports are properly configured and working properly. the problem appears on all boards when restarting . currently I switch my leds as below:after the problem comes from the initialization of the GPIO ports of your card when restarting not my code (otherwise it will not work in manual …)
PIN_LED_DEFAUT = 13;
exportGPIO(PIN_LED_DEFAUT);
setDirectionGPIO(PIN_LED_DEFAUT,“out”);
int etat_led_defaut = 0;
while(1)
{
setValueGPIO(PIN_LED_DEFAUT, etat_led_defaut, PIN_LED_DEFAUT, api1, 1, &flag_erreur_API);
usleep(500000);// sleep 1/2 seconde
etat_led_defaut = !etat_led_defaut;
}
-
Note that if ethernet is used for communicating to another system for the L.E.D., then networking must be set up; if WiFi is involved, then GUI login changes how to make this work, but if wired ethernet is already set up, then this won’t be an issue. It is important to know how the program communicates with outside systems if the L.E.D. in question is not connected to the local system. : the GPIO port command is directly connected on the pins no communication exists . the GPIO opening commands are launched by the . /a.out command with the terminal. a.out that works in manual therefore this is not a problem of port configurations or utilisation.
-
Note that if ethernet is used for communicating to another system for the L.E.D., then networking must be set up; if WiFi is involved, then GUI login changes how to make this work, but if wired ethernet is already set up, then this won’t be an issue. It is important to know how the program communicates with outside systems if the L.E.D. in question is not connected to the local system. : I am connected directly on the board not by Ethernet or others the problem does not come from this.
-
Tip: “” shows who is logged in , but does not say who is running the script (not definitively). The system runs various processes from non-login processes. You should replace “” with:
whowho:
I have already tried this the user who connects is airoddev and it is he who runs the script. otherwise how can I add to my sh script the automatic manual launch forcing by checking that all libraries have been correctly instantiated for simulate a manuel launch.
I modified the file . sh to export the environment variables of the whole system before launching my program but nothing does it when restarting the card the GPIOs are not active
here is what the . Bash contains :
#!/bin/bash -e
NAME: gui-launcher
DE_SESSION=“${1}”
BEGIN INIT INFO
echo $(who)
echo $(pwd)
echo “Attente de configuration user”
sleep 10
if running bash
if [ -n “$BASH_VERSION” ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
set PATH so it includes user’s private bin if it exists
if [ -d “$HOME/bin” ] ; then
PATH="$HOME/bin:$PATH"
fi
set PATH so it includes user’s private bin if it exists
if [ -d “$HOME/.local/bin” ] ; then
PATH="$HOME/.local/bin:$PATH"
fi
if [[ “$DE” == “gnome” ]]; then export_environ “$(pgrep gnome-session -n -U $UID)”
elif [[ “$DE” == “gnome-classic” ]]; then export_environ “$(pgrep gnome-session -n -U $UID)”
fi
Check whether the user is logged-in
while [ -z “$(pgrep gnome-session -n -U $UID)” ]; do sleep 3; done
Export the current desktop session environment variables
export $(xargs -0 -a “/proc/$(pgrep gnome-session -n -U $UID)”)
[3.] Get the name of the current Desktop Environment
#XDG_CURRENT_DESKTOP=$(echo -e “${XDG_CURRENT_DESKTOP[@]}” | get_frequent)
echo “Lancement machine”
Execute the input command
gnome-terminal – bash -c “/home/airoddev/projects/SW_embarque_sexage/a.out”;exec bash
exit 0
And below the answer :
airoddev :0 2021-05-07 15:42 (:0)
/home/airoddev
Attente de configuration user
declare -x CLUTTER_IM_MODULE=“xim”
declare -x COLORTERM=“truecolor”
declare -x DBUS_SESSION_BUS_ADDRESS=“unix:path=/run/user/1000/bus”
declare -x DEFAULTS_PATH=“/usr/share/gconf/ux-ubuntu.default.path”
declare -x DESKTOP_SESSION=“ux-ubuntu”
declare -x DISPLAY=“:0”
declare -x GDMSESSION=“ux-ubuntu”
declare -x GENICAM_GENTL64_PATH=“:/home/airoddev/Vimba_4_2/VimbaGigETL/CTI/arm_64bit:/home/airoddev/Vimba_4_2/VimbaUSBTL/CTI/arm_64bit”
declare -x GJS_DEBUG_OUTPUT=“stderr”
declare -x GJS_DEBUG_TOPICS=“JS ERROR;JS LOG”
declare -x GNOME_DESKTOP_SESSION_ID=“this-is-deprecated”
declare -x GNOME_SHELL_SESSION_MODE=“ubuntu”
declare -x GNOME_TERMINAL_SCREEN=“/org/gnome/Terminal/screen/f7aa1b1d_9d9b_49c1_ad91_f53ea49f6368”
declare -x GNOME_TERMINAL_SERVICE=“:1.91”
declare -x GPG_AGENT_INFO=“/run/user/1000/gnupg/S.gpg-agent:0:1”
declare -x GTK_IM_MODULE=“ibus”
declare -x GTK_MODULES=“gail:atk-bridge”
declare -x HOME=“/home/airoddev”
declare -x IM_CONFIG_PHASE=“2”
declare -x JETSON_BOARD=“P3449-0000”
declare -x JETSON_BOARDIDS=“3448”
declare -x JETSON_CHIP_ID=“33”
declare -x JETSON_CODENAME=“porg”
declare -x JETSON_CUDA=“10.2.89”
declare -x JETSON_CUDA_ARCH_BIN=“5.3”
declare -x JETSON_CUDNN=“8.0.0.180”
declare -x JETSON_JETPACK=“4.4”
declare -x JETSON_L4T=“32.4.3”
declare -x JETSON_L4T_RELEASE=“32”
declare -x JETSON_L4T_REVISION=“4.3”
declare -x JETSON_MACHINE=“NVIDIA Jetson Nano (Developer Kit Version)”
declare -x JETSON_MODULE=“P3448-0000”
declare -x JETSON_OPENCV=“4.1.1”
declare -x JETSON_OPENCV_CUDA=“NO”
declare -x JETSON_SERIAL_NUMBER=“”
declare -x JETSON_SOC=“tegra210”
declare -x JETSON_TENSORRT=“7.1.3.0”
declare -x JETSON_TYPE=“Nano (Developer Kit Version)”
declare -x JETSON_VISIONWORKS=“1.6.0.501”
declare -x JETSON_VPI=“0.3.7”
declare -x JETSON_VULKAN_INFO=“1.2.70”
declare -x LANG=“fr_FR.UTF-8”
declare -x LD_LIBRARY_PATH=“/usr/local/cuda-10.2/lib64”
declare -x LESSCLOSE=“/usr/bin/lesspipe %s %s”
declare -x LESSOPEN=“| /usr/bin/lesspipe %s”
declare -x LIBRARY_PATH=“:/usr/local/cuda-10.2/lib64”
declare -x LOGNAME=“airoddev”
declare -x LS_COLORS=“rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:.tar=01;31:.tgz=01;31:.arc=01;31:.arj=01;31:.taz=01;31:.lha=01;31:.lz4=01;31:.lzh=01;31:.lzma=01;31:.tlz=01;31:.txz=01;31:.tzo=01;31:.t7z=01;31:.zip=01;31:.z=01;31:.Z=01;31:.dz=01;31:.gz=01;31:.lrz=01;31:.lz=01;31:.lzo=01;31:.xz=01;31:.zst=01;31:.tzst=01;31:.bz2=01;31:.bz=01;31:.tbz=01;31:.tbz2=01;31:.tz=01;31:.deb=01;31:.rpm=01;31:.jar=01;31:.war=01;31:.ear=01;31:.sar=01;31:.rar=01;31:.alz=01;31:.ace=01;31:.zoo=01;31:.cpio=01;31:.7z=01;31:.rz=01;31:.cab=01;31:.wim=01;31:.swm=01;31:.dwm=01;31:.esd=01;31:.jpg=01;35:.jpeg=01;35:.mjpg=01;35:.mjpeg=01;35:.gif=01;35:.bmp=01;35:.pbm=01;35:.pgm=01;35:.ppm=01;35:.tga=01;35:.xbm=01;35:.xpm=01;35:.tif=01;35:.tiff=01;35:.png=01;35:.svg=01;35:.svgz=01;35:.mng=01;35:.pcx=01;35:.mov=01;35:.mpg=01;35:.mpeg=01;35:.m2v=01;35:.mkv=01;35:.webm=01;35:.ogm=01;35:.mp4=01;35:.m4v=01;35:.mp4v=01;35:.vob=01;35:.qt=01;35:.nuv=01;35:.wmv=01;35:.asf=01;35:.rm=01;35:.rmvb=01;35:.flc=01;35:.avi=01;35:.fli=01;35:.flv=01;35:.gl=01;35:.dl=01;35:.xcf=01;35:.xwd=01;35:.yuv=01;35:.cgm=01;35:.emf=01;35:.ogv=01;35:.ogx=01;35:.aac=00;36:.au=00;36:.flac=00;36:.m4a=00;36:.mid=00;36:.midi=00;36:.mka=00;36:.mp3=00;36:.mpc=00;36:.ogg=00;36:.ra=00;36:.wav=00;36:.oga=00;36:.opus=00;36:.spx=00;36:.xspf=00;36:”
declare -x MANDATORY_PATH=“/usr/share/gconf/ux-ubuntu.mandatory.path”
declare -x OLDPWD
declare -x PATH=“/home/airoddev/.local/bin:/home/airoddev/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/local/cuda/bin”
declare -x PWD=“/home/airoddev”
declare -x QT4_IM_MODULE=“xim”
declare -x QT_ACCESSIBILITY=“1”
declare -x QT_IM_MODULE=“ibus”
declare -x SESSION_MANAGER=“local/airoddev:@/tmp/.ICE-unix/5913,unix/airoddev:/tmp/.ICE-unix/5913”
declare -x SHELL=“/bin/bash”
declare -x SHLVL=“3”
declare -x SSH_AGENT_PID=“6404”
declare -x SSH_AUTH_SOCK=“/run/user/1000/keyring/ssh”
declare -x TERM=“xterm-256color”
declare -x TEXTDOMAIN=“im-config”
declare -x TEXTDOMAINDIR=“/usr/share/locale/”
declare -x USER=“airoddev”
declare -x USERNAME=“airoddev”
declare -x VTE_VERSION=“5202”
declare -x WINDOWPATH=“1”
declare -x XAUTHORITY=“/run/user/1000/gdm/Xauthority”
declare -x XDG_CONFIG_DIRS=“/etc/xdg/xdg-ux-ubuntu:/etc/xdg”
declare -x XDG_CURRENT_DESKTOP=“ubuntu:GNOME”
declare -x XDG_DATA_DIRS=“/usr/share/ux-ubuntu:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop”
declare -x XDG_MENU_PREFIX=“gnome-”
declare -x XDG_RUNTIME_DIR=“/run/user/1000”
declare -x XDG_SEAT=“seat0”
declare -x XDG_SESSION_DESKTOP=“ux-ubuntu”
declare -x XDG_SESSION_ID=“1”
declare -x XDG_SESSION_TYPE=“x11”
declare -x XDG_VTNR=“1”
declare -x XMODIFIERS=“@im=ibus”
Lancement machine
after that on this call manualy its okay (program run and led blinking) after reboot the program run but Nothing led blinkg
Can you perform an auto start and grep the logs for anything related to that exact GPIO (case insensitive search, but I don’t know which particular GPIO it is, e.g., maybe it is marked as “275”) and post the results before you manually launch? Also, before manual launch, what do you see when you examine current GPIO exports? Probably the list of GPIOs is found via:
sudo ls -l /sys/class/gpio/gpio*
Also, what is the content (after auto run, but before manual run) of (this is probably the right file location, but it might differ on some releases):
sudo cat /sys/kernel/debug/gpio
Then, watch “dmesg --follow”, and see if new log content shows up when you manually launch? If am curious if the “/sys/kernel/debug/gpio” has changed, or if log messages are entered due to the kernel doing some configuration.
For the C code above, is this spelling a typographic error?
PIN_LED_DEFAUT
…if so, then it probably wants “PIN_LED_DEFAULT” and the init would fail (but then later something might occur which actually sets a value). Most likely it is a typo while posting since compile would otherwise fail (on the other hand, maybe you wrote your own GPIO wrappers and this is a french version of english “DEFAULT”…sorry, I have only a very slight knowledge of the french language). Basically though I want to confirm that your init actually did init, and that when a run does actually succeed, that the exported GPIO (including in/out defaults) has not actually change (an indicator of init being at fault rather than the basic use and auto run).
You are probably correct, but “whoami” would guarantee it via the line in your script, whereas “who” does not verify the script is running by that user. I have no doubt you are correct, but it is something worth pointing out since “who” is unrelated to the script which runs the command. It is a system level list of logged in regular users (it won’t list system users). On the other hand, your changes go well above and beyond changing that! :)
Other than verifying the init prior to manual run, along with comparison to the exports and other init settings after manual run succeeds there is not much else left. One thing you could do is to actually build a command into the a.out program to record the content of “/sys/kernel/debug/gpio” before and after init, and save a copy of the content to a log file for “before” and a log file for “after”. Then diff the two log files before manual run, along with diffing the resulting files after manual run. I think it is critical to know that the GPIO really was in the expected state before moving on. We know what the state should be, but because there is a bug somewhere we more or less must verify and cannot assume. It is a pain to do so, and it shouldn’t be necessary, but actually testing if export and GPIO state is what we expect is the only way to guarantee progress (I could guess all day and it wouldn’t save any time). Obviously auto run and manual run has something different going on, and the step after this would be to run with strace, and that implies a lot of debug log to go through.