Schnell ein Script geschrieben:
/home/pi/chronometer
Lokal (händisch) aufgerufen funktioniert es.
In crontab -e eingetragen als:
passiert wieder genau nichts. Auch keine Fehlermeldung oder so.
Das letzte in /var/log/messages lautet:
Schnell ein Script geschrieben:
/home/pi/chronometer
Lokal (händisch) aufgerufen funktioniert es.
In crontab -e eingetragen als:
passiert wieder genau nichts. Auch keine Fehlermeldung oder so.
Das letzte in /var/log/messages lautet:
Mal wieder: LCD Display? Schau mal ob du hier fündig wirst!
Wenn Du die Ausgaben nach /dev/null, also ins Nirvana und nicht in eine Datei schickst, wirst Du auch keine Fehlermeldungen erfahren.
Wenn Du die Ausgaben nach /dev/null, also ins Nirvana und nicht in eine Datei schickst, wirst Du auch keine Fehlermeldungen erfahren.
Damit hast Du natürlich völlig recht. Das war unüberlegt von mir.
Diese Umleitungsgeschichte am Ende einer Zeile bei Crontab ist so drin bei mir, ohne zu hinterfragen, was da eigentlich passiert. Den Ausdruck 2>&1 hab ich bis heute nicht verstanden.
Aber zurück zum Kern.
Einen Fehler habe ich jetzt gefunden. Bei meinem letzen Konstrukt mit dem Shellscript konnte pihole nicht ausgeführt werden, weil der Pfad im Script fehlte. Also der klassische Fehler, dass Cron in einer anderen Umgebung läuft, als pi@. Das habe ich jetzt korrigiert und das Script sieht jetzt so aus:
Die Zeile in der Crontab hab ich abgeändert auf:
Immernoch ohne zu wissen, was der 2>&1 Ausdruck bewirkt.
Das Ergebnis ist, dass das Script jetzt immerhin schon ausgeführt wird, es mir aber innerhalb von 2 Minuten ca. 82 kByte in /home/pi/chronometer.err schreibt. Hier mal ein Ausschnitt des Inhalts. Die erste Zeile irritiert mich:
'unknown': I need something more specific.
|¯¯¯(¯)_|¯|_ ___|¯|___ Core: v5.2.4.
| ¯_/¯|_| ' \/ _ \ / -_) Web: v5.4.
|_| |_| |_||_\___/_\___| FTL: v5.7.
——————————————————————————————————————————————————————————
Hostname: raspi3 (Raspberry Pi 3, Model B+)
Uptime: 00:04:57
Task Load: 2.10 1.36 0.61 (Active: 2 of 77 tasks)
CPU usage: 2% (4x 1.4 GHz @ 59c)
RAM usage: 17% (Used: 158 MB of 924 MB)
HDD usage: 30% (Used: 4 GB of 14 GB)
LAN addr: 192.168.178.10 (Gateway: 192.168.178.1)
Pi-hole: Active (Blocking: 75718 sites)
Ads Today: 24% (Total: 5271 of 21568)
Local Qrys: 38% (8 DNS servers)
Blocked: incoming.telemetry.mozilla.org
Top Advert: wpad.fritz.box
Top Domain: raspi3.fritz.box
Top Client: DESKTOP-XXXXXXX.fritz.box
Alles anzeigen
Dieser Block wiederholt sich ständig, vermutlich bei jedem refresh.
Da steht also genau das, was ich eigentlich auf dem LCD sehen möchte. Sogar in bunt. Ich tippe mal auf einen Umleitungsfehler als Ursache für die Ausgabe der Anzeige in die Datei?
Lg
Günther
Die 2 steht für die Fehlerausgabe und die 1 für die normale Ausgabe, die ein Skript (z.B. durch ein echo "Hallo") machen könnte.
Siehe dazu u.a. hier: https://wiki.ubuntuusers.de/Shell/Umleitun…anaele-der-Bash
Btw. Setz mal DISPLAY=:1 in den Cronjob vor das Skript und das sleep in das Skript.
Die 2 steht für die Fehlerausgabe und die 1 für die normale Ausgabe, die ein Skript (z.B. durch ein echo "Hallo") machen könnte.
Dann müsste also zur reinen Fehlerumleitung in eine Datei der Aufruf am Ende der Zeile in crontab >/verz/dateiname 2 lauten?
Btw. Setz mal DISPLAY=:1 in den Cronjob vor das Skript und das sleep in das Skript.
Das habe ich gemacht und neu gestartet. Leider ohne Änderung. Die Ausgabe geht weiterhin nach chronometer.err
Die erste Zeile 'unknown': I need something more specific ist allerdings nicht mehr vorhanden.
Nein, dann so
/home/pi/chronometer 2> /home/pi/chronometer.err
Nein, dann so
/home/pi/chronometer 2> /home/pi/chronometer.err
So ganz langsam wird mir die Arbeitsweise etwas klarer.
Ich hab das gleich eingebaut und nun erfolgt nicht mehr die komplette Ausgabe in die Fehlerprotokolldaeit, dafür erscheint jetzt die Zeile
'unknown': I need something more specific. im log. DISPLAY=:1 steht weiterhin in der Crontab, die Sleep-Anweisung im Script.
Eine Ausgabe auf dem LCD erfolgt weiterhin nicht.
Lokal (händisch) aufgerufen funktioniert es.
Füge der Crontab mal über dem ersten Cronjob die Zeile SHELL=/bin/bash ein und verwende im Skript mal den Shebang #!/bin/bash statt #!/bin/sh!
Mir gehen ehrlich gesagt so langsam die Ideen aus, zumindest was die Crontab betrifft.
Hast Du denn mal den export der Displayvariable probiert?
Entschuldige, dass meine Antwort erst so spät kommt. Muss nur gelegentlich auch den alltäglichen Dingen außerhalb des Hobby nachgehen.
Füge der Crontab mal über dem ersten Cronjob die Zeile SHELL=/bin/bash ein und verwende im Skript mal den Shebang #!/bin/bash statt #!/bin/sh!
Das mit /bin/bash als Shell in der Crontab und im Script hab ich umgesetzt. Die Auswirkung war gleich Null. Deshalb hab ich beides erstmal wieder zurück auf /bin/sh geschrieben.
Mir ist aufgefallen dass der @reboot Eintrag wohl immer und immer wieder ausgeführt wird. Ich ging bislang davon aus, das der nur einmal beim starten ausgeführt wird?
Drauf gekommen bin ich, weil die chronometer.err Datei so ca alle 10 Sekunden eine weitere Zeile 'unknown': I need something more specific. dazubekommt.
Mir gehen ehrlich gesagt so langsam die Ideen aus, zumindest was die Crontab betrifft.
Ich bekomme hier auch langsam eine Krise. Es kann doch nicht so scheinbar unmöglich sein, auf einem System ein Script mit Displayausgabe automatisch zu starten. Oder kommt das so selten vor?
Ich hatte kurzfristig auch schon den Gedanken, ob es vllt sinnvoll ist, einen extra Benutzer anzulegen, der sich automatisch einloggt und dessen Shell das chronometer-script ist. Wäre das evtl eine Option?
Lg
Günther
Hast Du denn mal den export der Displayvariable probiert?
Das habe ich gerade eben erst aufgegriffen und so in dem chronometer-script ausprobiert:
Auswirkungen hat es aber nicht gehabt, denn ein echo $DISPLAY (direkt an der Konsole vom RPI) liefert nur eine leere Ausgabe zurück. Hab ich's an der falschen Stelle eingebaut? Oder falsch notiert?
Lg
Günther
Ich hatte kurzfristig auch schon den Gedanken, ob es vllt sinnvoll ist, einen extra Benutzer anzulegen, der sich automatisch einloggt und dessen Shell das chronometer-script ist. Wäre das evtl eine Option?
Du wirst lachen, aber das schrieb ich schon imBeitrag #15. Den hatte ich aber gelöscht, weil Du schon im Beitrag vorher... während ich noch schrieb.
Habe den jetzt mal wiederhergestellt.
Auf die schnelle... Der User heißt hier brot. Mir fallen keine besseren Namen ein und udo war zu nahe an sudo.
User erstellen mit: sudo adduser brot
brot der Gruppe sudo hinzufügen:sudo usermod -aG sudo brot
Wechseln zu brot: sudo su brot
Als brot 'automatisch ins CLI booten' einstellen: sudo raspi-config
wieder zu pi werden: exit
brot aus der Gruppe sudo werfen: sudo deluser brot sudo
Hast Du die .bashrc als pi2 oder als pi bearbeitet?
Was ist die Ausgabe von ls -lisa /home/pi2/.bashrc?
Hast Du die .bashrc als pi2 oder als pi bearbeitet?
Als pi2 bearbeitet. Die Datei gehört doch auch pi2, so war mein Gedankengang)
Die Ausgabe ergibt:
258200 4 -rw-r--r-- 1 pi2 pi2 3536 Apr 1 15:16 /home/pi2/.bashrc
User pi2 ist in der primären Gruppe pi2, sonst in keiner weiteren.
Die ./bashrc ist original, bis auf die letzte Zeile:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth
# append to the history file, don't overwrite it
shopt -s histappend
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
# If set, the pattern "**" used in a pathname expansion context will
# match all files and zero or more directories and subdirectories.
#shopt -s globstar
# make less more friendly for non-text input files, see lesspipe(1)
#[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"
# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color|*-256color) color_prompt=yes;;
esac
# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
force_color_prompt=yes
if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w \$\[\033[00m\] '
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt
# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac
# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'
alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
fi
# colored GCC warnings and errors
#export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'
# some more ls aliases
#alias ll='ls -l'
#alias la='ls -A'
#alias l='ls -CF'
# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi
pihole -c
#
Alles anzeigen
Lg
Günther
Pfff! Schwer zu sagen an welcher Gruppe es hängt. Ich würde pauschal mal auf adm tippen.
sudo usermod -aG adm pi2
Dann kämen noch ein paar andere in Frage, in denen pi ist.
:~ $ groups
pi adm dialout cdrom sudo audio video plugdev games users input netdev lpadmin gpio i2c spi
Die Gruppe sudo würde ich vermeiden und pi natürlich auch.
//Edit
Hier eine Übersicht: https://wiki.debian.org/SystemGroups
Schwer zu sagen an welcher Gruppe es hängt.
Ich hab die genannten alle einzeln duchprobiert. Wollte natürlich sowenig wie möglich Rechte dem User pi2 zugestehen. Deshalb einzeln, was natürlich etwas gedauert hat.
Gebracht hat es am Ende nichts, denn es wird nach wie vor nach dem root passwort gefragt.
Hab ich mich zwischendurch eigentlich für Deine Engelsgedund schon einmal bedankt? Nun, an dieser Stelle tu ich es hiermit. Ich find's echt toll, wie Du Dich da reinkniest.
Lg
Günther
Ergänzung.
Ich hab mal aus pihole den Abschnitt herausgesucht, wo vermutlich die sudo Abbrüfung erfolgt. Vielleicht hilft das weiter
Kann es denn nicht mal einfach sein!
Ok, dann setz den User pi2 wieder in die Gruppe sudo und in ändere in der /home/pi2/.bashrc die Zeile in sudo pihole -c. Bzw. lass den Eintrag in der .bashrc erstmal so. Vielleicht reicht das schon
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!