/var/log/debug für Joachim B.

[Kommandozwile vor demFrühstück für Alle! (Gast)]

> Sheeva P. schrieb:
> > Ich verstehe nicht ganz, was Du vorhast, aber Deine Befehlsfolge ist
> > etwas ... sagen wir, merkwürdig. Was genau möchtest Du denn machen?
> > Warum willst Du in /var/log herumschreiben? Reicht Dir vielleicht ein:
> > sudo grep -v Synergy /var/log/debug | tail -300
> >
> ... und wenn nicht, warum nicht?
>
> weil es nicht funktioniert?
> eben probiert mit
> > sudo grep -v Synergy /var/log/debug | tail -300
>
> aber weder ist Synergy aus debug entfernt noch ist debug
>  gekürzt auf tail -300
>
> Das File debug ist wieder 862 Zeilen lang mit reichlich Synergy Zeilen,
> genau das sollte ja nicht sein!

ich verkneife mir nun explizit die Frage nach dem warum du auf diesem 
Wege beharrst, aber:

$ sudo  sh -c  'mv  -v  /var/log/debug  /tmp/debug.orig  \
                &&  grep  -v Synergy  |  tail -n300  \
                > /var/log/debug'
$ 
$ # kontrolle
$ wc -l  /var/log/debug
300
$ grep -c Synergy  /var/log/debug
0
$

Meckere nicht, was mit deinem System weiter passiert - YMMV.

[Joachim B. (jar)]

Kommandozwile vor demFrühstück für Alle! schrieb:
> ich verkneife mir nun explizit die Frage nach dem warum du auf diesem
> Wege beharrst

darfst ruhig fragen

ich habe Kartensterben erlebt, ausbremsen vom OS und untersuche die 
Gründe, alle Linuxliebhaber sagten ich soll in den LOG Files nachsehen 
was ich nun endlich mal tat, statt den obligatorischen win reset Trick 
zu wählen der ja bei Linux unnötig sein soll.

Kommandozwile vor demFrühstück für Alle! schrieb:
> warum du auf diesem
> Wege beharrst

weil mir das so vorgeschlagen wurde

und ich das als Lösung sah

so wie 2001 beim NAS2001b Webserver der regelmäßig abschmierte, der 
würgaround Hack funktionierte aber sicher und ich dachte dann auch auf 
dem PI

http://forum.nas-forum.org/index.php?page=Thread&threadID=277

also DANKE ich probiere auch deinen Vorschlag.

[Joachim B. (jar)]

eben mit syslog probiert!

pi@raspbianPI3:~ $ sudo  sh -c  'mv  -v  /var/log/syslog 
/tmp/syslog.orig  \
>                 &&  grep  -v Synergy  |  tail -n300  \
>                 > /var/log/syslog'
„/var/log/syslog“ -> „/tmp/syslog.orig“

so Syslog ist nun 0 Bytes groß, das ist irgendwie was anderes als nur 
die Synergyeinträge zu löschen und tail -300 anzuwenden

wieder ein gut gemeinter Tipp der leider nicht funktioniert, woran liegt 
das?

[DPA (Gast)]

Vermutlich müsste es statt "grep -v Synergy" "grep -v Synergy 
/tmp/debug.orig" heissen, von stdin kommt ja nichts.

Mit Rsyslog könnte man filter einrichten, dann brauchte man das grep 
garnicht erst:
https://serverfault.com/questions/15106/is-there-a-way-to-filter-syslog-entries
Rsyslog würde auch maximale Logfile grössen unterstützen, aber leider 
nicht basierend auf anzahl Zeilen, braucht ja aber sonst auch keiner. 
Das tail und mv müsste man also noch selbst machen.

Ich logge mein Zeugs sowieso direkt auf meinen Logserver, auf ne 
separate Partition, dann habe ich gleich alles an einem Ort. Wobei, dank 
systemds journald würde die rsyslog Lösung ja auch nur noch mit 
unnötigen Verrenkungen gehen.

Aber wie auch immer, wenn du eine laufende Lösung hast, und dich nicht 
damit herum schlagen willst, dann lass es doch einfach.

PS: Friss den Trollen nicht aus der Hand, der Thread wurde vermutlich 
nicht erstellt, um dir oder sonst jemanden zu helfen. Obwohl, eventuell 
habt ihr ja sogar das selbe Motiv.

[Johannes S. (Gast)]

falls es nur um das Synergy Logging ging: das kann man auch abschalten 
oder auf Error setzen, per default müllt Synergy das log leider ziemlich 
voll.

[Kommandozeile vor dem Frühstück für Alle! (Gast)]

DPA schrieb:
> Vermutlich müsste es statt "grep -v Synergy" "grep -v Synergy
> /tmp/debug.orig" heissen, von stdin kommt ja nichts.

Exakt. Da sind 2 Fehler.
Der erste von mir weil ich die Datei vergass hinzuschreiben, der zweite 
von Joachim weil er blind abschreibt und nicht kapieren will was er da 
abzuschreiben hat.
(wenn bei GUI gesagt wird "click oben rechts auf das [X] und du bist das 
Problem los", wird ja auch nicht blind das Programmfenster geschlossen, 
oder doch?)

> Mit Rsyslog könnte man filter einrichten, dann brauchte man das grep
> garnicht erst:
> https://serverfault.com/questions/15106/is-there-a...
> Rsyslog würde auch maximale Logfile grössen unterstützen, aber leider
> nicht basierend auf anzahl Zeilen, braucht ja aber sonst auch keiner.
> Das tail und mv müsste man also noch selbst machen.

Deswegen meine nicht-nachfrage zum warum. Die korrekte Vorgehensweise 
ist nicht das Zuviel wegzumachen, sondern dies gar nicht entstehen zu 
lassen.
Konkret hier: warum muss Synergy mit Debug-Ausgaben laufen?
Da gehoert der Hebel angesetzt.
("Kartensterben" und dann noch mehr Dateioperationen... WTF?)

> Aber wie auch immer, wenn du eine laufende Lösung hast, und dich nicht
> damit herum schlagen willst, dann lass es doch einfach.
>
> PS: Friss den Trollen nicht aus der Hand, der Thread wurde vermutlich
> nicht erstellt, um dir oder sonst jemanden zu helfen. Obwohl, eventuell
> habt ihr ja sogar das selbe Motiv.

Den Thread habe ich erstellt weil zum einen Joeachims Frage OT im 
anderen Thread ist (dort geht es um FF) und weil jener Thread im 
Offtopic steckt wo Gaeste nicht hinschreiben koennen.

[Johannes S. (Gast)]

Kommandozeile vor dem Frühstück für Alle! schrieb:
> Den Thread habe ich erstellt weil zum einen Joeachims Frage OT im
> anderen Thread ist (dort geht es um FF)

Da wäre es sinnvoll in der Eröffnung auch einen Link auf den 
Originalthread reinzusetzen.

[DPA (Gast)]

Kommandozeile vor dem Frühstück für Alle! schrieb:
> Den Thread habe ich erstellt weil zum einen Joeachims Frage OT im
> anderen Thread ist

Aber einen Thread aufzumachen und seine Frage zu stellen ist doch nicht 
deine Angelegenheit. Falls er die Frage stellen will, dann lass ihn das 
doch selbst machen.

[Karl Käfer (Gast)]

Joachim B. schrieb:
> Kommandozwile vor demFrühstück für Alle! schrieb:
>> ich verkneife mir nun explizit die Frage nach dem warum du auf diesem
>> Wege beharrst
>
> darfst ruhig fragen
>
> ich habe Kartensterben erlebt, ausbremsen vom OS und untersuche die
> Gründe, alle Linuxliebhaber sagten ich soll in den LOG Files nachsehen
> was ich nun endlich mal tat, statt den obligatorischen win reset Trick
> zu wählen der ja bei Linux unnötig sein soll.

Ok, Du willst also den Term "Synergy" aus Deiner Logdatei filtern und 
die letzten 300 Zeilen davon anschauen. Nichts leichter als das:

sudo grep -v Synergy /var/log/debug | tail -n 300 | less -S

Jetzt werden die letzten 300 Zeilen Deiner gefilterten Logdatei in 
"less" angezeigt. Du kannst mit den Pfeiltasten herauf und herunter und 
beim Bedarf nach rechts und links scrollen und den "less" mit einem 
Druck auf die Taste "q" wieder verlassen.

Wenn Du Deine Ausgabe unbedingt in einer eigenen Datei haben willst 
kannst Du das '| less -S' weglassen und stattdessen "> datei.txt" 
angeben. Dann liegen die Logdaten eben in der Datei "datei.txt" die Du 
naürlich auch anders nennen kannst.

Du mußt also gar keine neue Datei anlegen oder Deinem Syslogd eine Datei 
unter dem Popo wegziehen. Außerdem ist die Datei /var/log/syslog der 
bessere Ausgangspunkt. Da hast Du doch bestimmt auch noch nicht hinein 
geschaut, oder?

> weil mir das so vorgeschlagen wurde

In dem anderen Thread hat Sheeva Dir das schon empfohlen, und ich tue es 
hier noch einmal: arbeite einfach ein halbwegs brauchbares Bash-Tutorial 
wie das von ihm verlinkte durch. Dann mußt Du Dich nicht auf halbgare 
Vorschläge verlassen, statt dessen weißt Du selbst wie und warum das 
richtig funktioniert.

Ich verstehe ehrlich nicht warum Du Dich so bockig anstellst. Wenn Du 
Linux benutzen willst dann lerne wie das geht. Im Gegensatz zu Windows 
ist fast alles sehr gut und in jeder gewünschten Detailtiefe 
dokumentiert. Du mußt es nur lesen und vielleicht ein bisschen 
herumspielen. Wenn Du das machst wirst Du sehr bald viel Freude mit 
Linux haben. Wenn nicht dann nicht.

[Joachim B. (jar)]

Kommandozeile vor dem Frühstück für Alle! schrieb:
> Konkret hier: warum muss Synergy mit Debug-Ausgaben laufen?

weiss ich auch nicht, war default und lies sich nicht abschalten, hatte 
ich schon versucht!

es sind ja auch mehr LOGs betroffen, daemon.log, syslog

[Joachim B. (jar)]

Kommandozeile vor dem Frühstück für Alle! schrieb:
> Konkret hier: warum muss Synergy mit Debug-Ausgaben laufen?

weiss ich auch nicht, war default und lies sich nicht abschalten, hatte 
ich schon versucht!

es sind ja auch mehr LOGs betroffen, daemon.log, syslog

Karl Käfer schrieb:
> Du mußt also gar keine neue Datei anlegen

das waren Vorschläge von "Linuxversteher"

Karl Käfer schrieb:
> Ich verstehe ehrlich nicht warum Du Dich so bockig anstellst.

ach?

Karl Käfer schrieb:
> Du mußt es nur lesen und vielleicht ein bisschen
> herumspielen.

mache ich seit Tagen ohne Erfolg!

aber ich stelle mich bockig an?
Ich dachte eher das tun die "Linuxversteher"

[Karl Käfer (Gast)]

Joachim B. schrieb:
> Karl Käfer schrieb:
>> Ich verstehe ehrlich nicht warum Du Dich so bockig anstellst.
>
> ach?

Ja.

> Karl Käfer schrieb:
>> Du mußt es nur lesen und vielleicht ein bisschen
>> herumspielen.
>
> mache ich seit Tagen ohne Erfolg!
>
> aber ich stelle mich bockig an?
> Ich dachte eher das tun die "Linuxversteher"

Deswegen haben Sheeva und ich versucht Dir Hilfe zur Selbsthilfe zu 
geben. Einfach das von Sheeva verlinkte Tutorial durcharbeiten. Dann 
brauchst Du nämlich keine "Linuxversteher" mehr sondern wirst selbst 
einer und dann kannst Dir selbst helfen.

[Johannes S. (Gast)]

Joachim B. schrieb:
> weiss ich auch nicht, war default und lies sich nicht abschalten, hatte
> ich schon versucht!

https://github.com/symless/synergy-core/wiki/Command-Line
-d für den Debug level

[Joachim B. (jar)]

Johannes S. schrieb:
> Joachim B. schrieb:
>> weiss ich auch nicht, war default und lies sich nicht abschalten, hatte
>> ich schon versucht!
>
> https://github.com/symless/synergy-core/wiki/Command-Line
> -d für den Debug level

hatte ich versucht funktionierte aber nicht!

-d level --debug level
use debugging level level.
Debug levels are from highest to lowest:  FATAL, ERROR, WARNING, NOTE, 
INFO, DEBUG, DEBUG1, and  DEBUG2.

vielleicht verstehe ich ERROR ja nicht

[Johannes S. (Gast)]

ich hatte es für Synergy1 mit '--debug ERROR' im startscript stehen, das 
hatte funktioniert. Aber mit dem upgrade auf stretch und Synergy2 ist 
wieder alles anders :-/

[Jiri D. (Gast)]

Keine Ahnung, wie das Synology-Zeug konkret eingerichtet ist, aber:

1. Für so Aufgaben, wie logfile regelmässig schließen, umbenennen, neues 
aufmachen gibt es logrotate. Kannst dann auch sagen, dass sie 
komprimiert werden sollen oder wie viele alte logfiles rumliegen bleiben 
sollen, uvam. (man logrotate)
2. Du kannst dem Synology-Prozess doch vermutlich auch sagen, dass er in 
ein anderes logfile, z.B. /var/log/synology.log, schreiben soll. Die 
meisten Tools können das. Dann siehe oben: logrotate.
3. Wenn du an den Synology Logeinträgen eh nicht interessiert bist, 
ändere die loglevel-Einstellungen, z.B. start-script, systemd unit file, 
oder /etc/$configfile.

[Johannes S. (Gast)]

ist nur blöd wenn so Einstellung mal hier mal da stehen, ich hatte es 
abgstellt und jetzt werden 3 Meldungen pro Sekunde geloggt. Aber Joachim 
verwendet so weit ich weiss noch Synergy1.

[Egon D. (Gast)]

Johannes S. schrieb:

> ist nur blöd wenn so Einstellung mal hier mal da stehen,
> ich hatte es abgstellt und jetzt werden 3 Meldungen pro
> Sekunde geloggt. Aber Joachim verwendet so weit ich weiss
> noch Synergy1.

Das übliche Problem: Userdokumentation ist inexistent,
schlecht auffindbar oder veraltet.

[Bernd K. (prof7bit)]

filter sie doch einfach im rsyslogd

[Johannes S. (Gast)]

ich hoffe das ist nicht OT wenn ich hier noch mal nach den Einstellungen 
für den Synergy2 Service frage, es geht mir hier auch wieder um das 
logging.
Es gibt wohl einen Kommandozeilenschalter um den debuglevel zu ändern, 
aber den finde ich zum verrecken nicht und das Sysmless Forum ist sehr 
träge.
Synergy2 startet einen Service 'synergy-service', der wiederum startet 
client oder server mit 'synergy-core'. Für synergy-service habe ich 
einen Eintrag in /lib/systemd/system/synergy.service gefunden:

[Unit]
Description=Synergy Service
After=network.target

[Service]
Type=simple
Restart=always
RestartSec=0
SyslogLevel=err
ExecStart=/usr/bin/synergy-service

[Install]
WantedBy=multi-user.target

Wenn ich an das ExecStart allerdings ein '-debug ERROR' anhänge startet 
der Dienst nicht mehr.
in /etc/synergy waren keine configs. Ich habe eine synergy.conf
[ocde]
ection: options
  debug = ERROR
  debuglevel = 0
end
[/code]
eingetragen, das wird aber ignoriert. Debugschalter sind in der Doku zum 
config file allerdings auch nicht aufgeführt.

Wie kann ich synergy-service Argumente mitgeben? Laut der spärlichen 
Beschreibng zu Synergy2 werden Argumente vom Aufrufer weitergegeben. Der 
system-core Prozess sieht aber immer so aus (weitere Argument 
weggelassen)

 /usr/bin/synergy-core --client -f --run-as-uid 1000 --display :0 --debug DEBUG

[DPA (Gast)]

Ich habe kein Synergy, kan dazu also nicht viel sagen.

Sind die Unterschiede nur Tippfehler im Post?

  -debug -> --debug
  ection -> section

Gibt es irgendein für /usr/bin/synergy-service eventuell eine Manpage 
oder sonstige Dokumentation, oder unterstützt es die --help option, oder 
ist es eventuell ein Script, in das man hinein scheuen kann?

[Johannes S. (Gast)]

danke,
section war ein Kopierfehler im Post, aber das wird sowieso ignoriert.
Dann scheint der synergy-service keine Argumente zu verstehen, im 
daemon.log stehen Fehlermeldungen das er --debug und -debug nicht 
versteht.

pi@JojosRPi3-1:~ $ synergy-service --help

Usage:
  synergy-service [OPTION...]

      --help            Print command line argument help
      --use-test-cloud  Connect to the test cloud server


pi@JojosRPi3-1:~ $ man synergy-service
Kein Handbucheintrag für synergy-service vorhanden
Siehe auch »man 7 undocumented« für Hilfe, wenn Handbuchseiten nicht verfügbar sind.
pi@JojosRPi3-1:~ $

auch das hilft leider nicht weiter. Werde mal den support anschreiben, 
das Rätsel raten macht keinen Spass mehr.

[Andrew T. (marsufant)]

Joachim B. schrieb:
>> Konkret hier: warum muss Synergy mit Debug-Ausgaben laufen?
>
> weiss ich auch nicht, war default und lies sich nicht abschalten, hatte
> ich schon versucht!
>
> es sind ja auch mehr LOGs betroffen, daemon.log, syslog

Du weißt sicherlich, das Du den Log-Daemon in seiner Konfiguration auch 
anweisen kannst, Deine Synergy Ausgaben in eigene Datei (die Du 
beleibig,  z.B. /etc/joachimb/synergy.log nennen kannst) ?

Das hilft nämlich ungemein, den Überblick über log-freudige Programme zu 
behalten und gleichzeitig die relevanten system Logs "clean" zu halten.

Einfach in die Konfig-Datei eintragen, kurzer hup auf den daemaon und 
vorher ein touch auf die /etc/joachimb/synergy.log


Ebenso daran denken, eine "aufräumskript" zu bauen, das derartige 
Dateien entweder Kürzt oder (besser) mit Zeitstempel wegsichert und dann 
neue /etc/joachimb/synergy.log toucht.
Kann man z.B. tages oder wochen-Rythmus machen, je nach Höhe des 
Meldungaufkommens.

[Joachim B. (jar)]

Johannes S. schrieb:
> Es gibt wohl einen Kommandozeilenschalter um den debuglevel zu ändern,
> aber den finde ich zum verrecken nicht und das Sysmless Forum ist sehr
> träge.
> Wenn ich an das ExecStart allerdings ein '-debug ERROR' anhänge startet
> der Dienst nicht mehr.

es gibt ein MAN für synergyc aber auch damit hatte ich keinen Erfolg, 
vermutlich am funktioniert es nicht oder falscher Aufruf

SYNERGYC(1)                                                        
NAME synergyc - synergy client

SYNOPSIS
       synergyc  [  --crypto-pass  password  ]  [ -d level | --debug level ] [
       --display display ] [ --daemon | { --no-daemon | -f } ] [ -l log-file |
       --log  log-file ] [ -n name | --name name ] [ --no-tray ] [ --no-xinit‐
       threads ] [ --restart | { --no-restart | -1 } ]  [  --yscroll  delta  ]
       address

ich nutze noch
pi@raspbianPI3:~ $ synergyc --version
synergyc 1.4.16, protocol version 1.5
Copyright (C) 2012 Bolton Software Ltd.
Copyright (C) 2008-2012 Nick Bolton
Copyright (C) 2002-2012 Chris Schoeneman

vielleicht sollte ich wirklich mal ein update versuchen


       synergyc  { --help | -h }

       synergyc  --version

Andrew T. schrieb:
> Du weißt sicherlich, das Du den Log-Daemon in seiner Konfiguration auch
> anweisen kannst

nein weiss ich nicht und ohne Beispiele wird es wieder ein tagelanges 
testen, sorry das macht mir jedenfalls nicht unbedingt Spass.

Wer ist "den Log-Daemon"?
"in seiner Konfiguration" hat schon mit debug nicht geklappt!

Solange hier jeder viel schwammiges und wenig hilfreiches schreibt wird 
mir Linux nicht unbedingt sympatischer.

Johannes S. schrieb:
> das Rätsel raten macht keinen Spass mehr.

sag ich doch andauernd

[DPA (Gast)]

Johannes S. schrieb:
> Wie kann ich synergy-service Argumente mitgeben? Laut der spärlichen
> Beschreibng zu Synergy2 werden Argumente vom Aufrufer weitergegeben. Der
> system-core Prozess sieht aber immer so aus (weitere Argument
> weggelassen) /usr/bin/synergy-core --client -f --run-as-uid 1000
> --display :0 --debug DEBUG

Kannst du eventuell den Aufruf "/usr/bin/synergy-core --client -f 
--run-as-uid 1000 --display :0 --debug ERROR" direkt ins Unitfile 
einsetzen, statt dem synergy-service?

[Johannes S. (Gast)]

Joachim B. schrieb:
> es gibt ein MAN für synergyc aber auch damit hatte ich keinen Erfolg,

ja, synergyc ist dokumentiert aber das ist 1er Version. Die Schalter 
gibt es noch, aber wie synergys und synergyc aufgerufen werden hat sich 
geändert und zu dem synergy-service finde ich nix. Bei der 1er musste 
man für RPi selber die Startscripts bauen, bei der 2er sind die nicht 
mehr nötig.
Wichtig war auf jeden Fall das die options case sensitiv sind, also 
kleines -d und komplett grosses ERROR.
Bei der 1er gab es auch ein GUI für die Einstellungen, in der 2er wurden 
die ganzen Einstellung entfernt und es wird als Vereinfachung 
verkauft...

DPA schrieb:
> Kannst du eventuell den Aufruf "/usr/bin/synergy-core --client -f
> --run-as-uid 1000 --display :0 --debug ERROR" direkt ins Unitfile
> einsetzen, statt dem synergy-service?

was ist das Unitfile? Es könnte gehen, aber ein Feature vom neueren 
synergy ist das man jeden Rechner vom client zum server umschalten kann. 
Bei mir ist der RPi idR der Client, aber so Sonderlösungen möchte ich 
vermeiden. Nach einem Update muss ich wahrscheinlich wieder basteln.

[Johannes S. (Gast)]

Joachim B. schrieb:
> vielleicht sollte ich wirklich mal ein update versuchen

zu der 1er Version hatte ich ja auch schon mein Leid geklagt, da war das 
Problem 100% Last auf einem Kern wenn der Serverrechner abgeklemmt 
wurde.

Nach Installations Odyssee war ich froh das die 2er endlich lief, aber 
nach deinem Thread sehe ich das es wieder eine tickende Bombe ist, es 
werden MB pro Minute geloggt. Wenn der Server nicht da ist muss ich 
nicht jede Sekunde darüber informiert werden. Ich verwende schon extra 
recht teure Sandisks, da ist es umso ärgerlicher wenn die durch so eine 
Müllprotokollierung geschreddert werden.

Joachim B. schrieb:
>> das Rätsel raten macht keinen Spass mehr.
>
> sag ich doch andauernd

wenn synergy nicht so ein cooles und einmaliges Tool wäre, dann hätte 
ich das auch schon längst in die Tonne getreten.

[35°C (Gast)]

Johannes S. schrieb:

>

>  /usr/bin/synergy-core --client -f --run-as-uid 1000 --display :0 
> --debug DEBUG
>

?


--log /dev/null

[Johannes S. (Gast)]

35°C schrieb:
> --log /dev/null

schön, und wo ändere ich die option? synergy-core wird vom 
synergy-service gestartet und da kann ich nicht eingreifen.

[Joachim B. (jar)]

Johannes S. schrieb:
> zu der 1er Version hatte ich ja auch schon mein Leid geklagt, da war das
> Problem 100% Last auf einem Kern wenn der Serverrechner abgeklemmt
> wurde.

das ist bei mir nicht so, wenn der Server aus ist benimmt sich der PI 
ganz normal

ich glaube das zeigte ich auch?
Die Last steigt nur wenn unter Synergy die Maus eintritt, aber nicht so 
stark das es den Rechner behindert.

[35°C (Gast)]

Johannes S. schrieb:
> 35°C schrieb:
>> --log /dev/null
>
> schön, und wo ändere ich die option? synergy-core wird vom
> synergy-service gestartet und da kann ich nicht eingreifen.

synergy-2+systemd ?


So oder so ähnlich wird das bei dir doch aussehen:

/lib/systemd/system/synergy@.service

Abschnitt [Service]

[Service]
ExecStart=/usr/bin/synergys -f -d WARNING –name Fedora -c 
/etc/synergy.conf -a 192.168.1.100:24800 –log /var/log/synergy.log
User=%i







---

hab kein systemd und werde es wohl nie gebrauchen ;)

[Johannes S. (Gast)]

nein, habe ich schon geschrieben: 
Beitrag "Re: /var/log/debug für Joachim B."

als ExecStart ist synergy-service angegeben und der akzeptiert keine 
Argumente, das führt zu einer entsprechenden Fehlermeldung und der 
service wird gar nicht gestartet.

[Johannes S. (Gast)]

der support hat gerade geantwortet:

Hi Johannes,
In Synergy 2 Beta, logging is done automatically, and unfortunately, at this time there is no way to change the logging status. I understand this is frustrating, and am happy to help in any other way that I can.

traurig traurig.
synergy verwendet eigene logfiles, kann man schreiben trotzdem durch 
Filter unterbinden?

[Egon D. (Gast)]

Johannes S. schrieb:

> synergy verwendet eigene logfiles, kann man schreiben
> trotzdem durch Filter unterbinden?

Irgendwas der Art

  ln -s /var/log/synergyzeugs.log /dev/null

ist nicht denkbar?

[Johannes S. (Gast)]

meine Unix Kentnisse sind bescheiden, aber einen link setzen heisst doch 
eine Datei zusätzlich unter anderem Namen zugänglich zu machen. Das hört 
sich für /dev/null nicht sinnvoll an.
Ein Vorschlag vom support war den synergy service zu stoppen wenn mein 
Server abgeklemmt wird, aber das ist ein unbequemer workaround weil der 
Server (Laptop) nahezu täglich zwischen home/work pendelt. Ich könnte 
den Dienst abgeschaltet lassen und nur per ssh shell aktivieren wenn ich 
ihn brauche. Aber benutzerfreundlich geht anders.
Ich hoffe das Symless das ändert, auf eMails reagiert der Support 
immerhin sehr schnell.

[Egon D. (Gast)]

Johannes S. schrieb:

> meine Unix Kentnisse sind bescheiden, aber einen link
> setzen heisst doch eine Datei zusätzlich unter anderem
> Namen zugänglich zu machen.

Kann man so sagen, ja.


> Das hört sich für /dev/null nicht sinnvoll an.

Wieso?
"/dev/null" wird zusätzlich unter dem Namen "/var/log/..."
zugänglich gemacht.

Was macht also der Daemon, wenn er /var/log/... beim
Start zum Schreiben öffnet?

[Daniel A. (daniel-a)]

Johannes S. schrieb:
> synergy verwendet eigene logfiles, kann man schreiben trotzdem durch
> Filter unterbinden?

Wenn es die System logging daemons umgeht, kann man darin nichts 
einstellen. Man könnte höchstens versuchen, mit fifos oder mit fuse 
etwas zu machen. z.B.:

rm /var/log/the-synergy-logfile.log             # logfile löschen
mkfifo -m 0777 /var/log/the-synergy-logfile.log # Mit fifo ersetzen
# Alles, was nach /var/log/the-synergy-logfile.log geschrieben wird, an den system logger weiterreichen. Funktioniert nur solange der Prozess läuft. Eventuell in ein Unitfile mit Autorestart packen:
stdbuf -o L grep -v Synergy /var/log/the-synergy-logfile.log | logger
# statt '|logger' wäre auch '>anderes_logfile.log' möglich.
# Das ganze funktioniert nur, solange die the-synergy-logfile.log Logs nicht rotiert werden.

[Johannes S. (Gast)]

Der Symless support hat geschrieben das man daran arbeitet das zu 
beheben, ich warte lieber auf das Update und stoppe den Dienst manuell 
wenn ich ihn nicht brauche. Nicht bequem, ist mir aber lieber als das 
System zu sehr zu verbasteln.

[Joachim B. (jar)]

Johannes S. schrieb:
> der support hat gerade geantwortet:
>
>

> Hi Johannes,
> In Synergy 2 Beta, logging is done automatically, and unfortunately, at 
> this time there is no way to change the logging status. I understand 
> this is frustrating, and am happy to help in any other way that I can.
>

>
> traurig traurig.
> synergy verwendet eigene logfiles, kann man schreiben trotzdem durch
> Filter unterbinden?

also ehrlich da bleibe ich lieber bei Synergy 1.4.15 oder so

ich habe jetzt einen Cronjob gestartet der jede Nacht um 2:00 Uhr die 
LOGs löscht, vermindert zwar nicht die Schreibbelastung auf der SD aber 
verhindert zumindest das Überlaufen.

Ich muss mich mal rannmachen eine RAMDISK zu installieren und die LOGs 
dahin auszulagern und nur gelegentlich auf die Platte zu bringen, 
vielleicht schaffe ich das ja auch die unnötigen Zeilen doch zu filtern, 
rauszuwerfen und tail anzuwenden, bis jetzt hat es ja trotz vieler Tipps 
nicht funktioniert!

[Andrew T. (marsufant)]

Joachim B. schrieb:
> Solange hier jeder viel schwammiges und wenig hilfreiches schreibt wird
> mir Linux nicht unbedingt sympatischer.

Nicht verzweifeln, Du mußt schon eigene Arbeit invertieren.

1. Schritt: man page lesen und verstehen

Man-Page sagt deutlich:

http://manpages.ubuntu.com/manpages/trusty/man1/synergyc.1.html

das Du das synergc mit der option --log LOGFILE starten kannst.

Das ist der Logfile, denn Du frei benennen kannst, und da kommen Deine 
Meldungen rein. Den Logfile MANUELL einmalig mit touch  auch anlegen, 
Berechtigungen korrekt setzen (gruppe/user)

Diesen File kannst du dann zyklisch mit tail, less, etc. "beharken", so 
wie es  Du es für Deine Anwendung haben möchtest. also auch filtern.

Ist letztlich bei allen unix-Versionen , Linux, etc. immer ähnlich.

d.h. schau bitte mal mit welcher Kommadozeile du den snergy starten lät 
-- wenn da keine derartige option gesetzt ist, dann mußt Du das dort 
nachholen.
Und ja, den synergy danach neu starten, sonst wird das ncith eingelesen.

Da muß man als Betreiber/Admin/Betreuer einfach durch.

[Joachim B. (jar)]

Andrew T. schrieb:
> Du mußt schon eigene Arbeit invertieren.

mach ich seit einer Woche, jede Menge Linuxfreunde helfen ja, aber bis 
jetzt ohne Erfolg

> Man-Page sagt deutlich:

DEUTLICH?
finde ich ja nicht,

meint das:
-d FATAL

 -d level           --debug level
                 use debugging level level.

                 Debug levels are from highest to lowest:  FATAL, 
ERROR,  WARNING,  NOTE,  INFO,
                 DEBUG,  DEBUG1,  and  DEBUG2.   Only  messages  at  or 
above the given level are
                 logged.   Messages  are  logged  to  a  terminal 
window  when  running  in  the
                 foreground, and to syslog when running as a daemon.

wie schreibt man das hin, nicht ein Beispiel!

debug=FATAL, -d=FATAL, -d FATAL, es gibt unzählige Möglichkeiten es 
FALSCH zu machen ohne Beispiel.

> http://manpages.ubuntu.com/manpages/trusty/man1/synergyc.1.html
> das Du das synergc mit der option --log LOGFILE starten kannst.

nix da ich starte es soger ohne Option LOG und trotzdem logT es 
ungewünscht.

> Das ist der Logfile, denn Du frei benennen kannst, und da kommen Deine
> Meldungen rein. Den Logfile MANUELL einmalig mit touch  auch anlegen,
> Berechtigungen korrekt setzen (gruppe/user)

da synergyc selbstständig logT ist es angelegt, aber wenn ich selbst als 
ROOT nicht grep und tail anwenden kann hat es keinen Sinn.

1. jeder einzelne Befehl
cp 2bak
grep -v
tail -100
mv2log

funktioniert, aber kaum lasse ich das als cronjob laufen funktioniert es 
nicht, selbst nicht mit stop service und start service oder mit kill 
synergyc und nach der Dateimanipulation wieder mit Neustart

> Diesen File kannst du dann zyklisch mit tail, less, etc. "beharken", so
> wie es  Du es für Deine Anwendung haben möchtest. also auch filtern.

habe ich schon viel versucht in vielerlei Variatioen.

> Ist letztlich bei allen unix-Versionen , Linux, etc. immer ähnlich.

dachte ich auch mal, hier bei meinem NAS2001b und dem 4220 hat es ja 
2009 funktioniert.

> d.h. schau bitte mal mit welcher Kommadozeile du den snergy starten lät
> -- wenn da keine derartige option gesetzt ist, dann mußt Du das dort
> nachholen.
> Und ja, den synergy danach neu starten, sonst wird das ncith eingelesen.

auch das habe ich mehrfach versucht.

> Da muß man als Betreiber/Admin/Betreuer einfach durch.
aber irgendwann soll der Compi ja kein Selbstzweck sein sondern ein 
Arbeitsmittel.
Man kann heute mit dme Compi Probleme lösen die man früher nicht hatte.

[DPA (Gast)]

Joachim B. schrieb:
> funktioniert, aber kaum lasse ich das als cronjob laufen funktioniert es
> nicht

Dann überprüfe/setze die PATH, das current working directory und die 
Shell. Am besten packt man das ganze in ein Script in /usr/local/bin/ 
und ruft dann in cron nur das Script auf.

[Kommandozeile vor dem Frühstück für Alle! (Gast)]

DPA schrieb:
> Joachim B. schrieb:
>> funktioniert, aber kaum lasse ich das als cronjob laufen funktioniert es
>> nicht
>
> Dann überprüfe/setze die PATH, das current working directory und die
> Shell. Am besten packt man das ganze in ein Script in /usr/local/bin/
> und ruft dann in cron nur das Script auf.

Das ist unsichere Praxis. Scripte als root welche unbeaufsichtigt laufen 
sollen besser ausgeschriebene Pfade zu den Programme verwenden, ggfs. 
per Variable kürzen. (übrigens wie in Makefiles auch). Maliziöse andere 
Programme könnten PATH manipulieren sodass zB. Ein anderes mv binary 
anstelle des gemeinten mv aufgerufen wird.

Wer Admin sein will muss sich als Admin benehmen!

-  -  -
Ausserdem denke ich, es könnte bei Joachim ein Missverständnis 
vorliegen.
tail ist ein Hilfsmittel um von einer gegebenen Datei nur max. die n 
letzten Zeilen in eine neue "Datei" zu übertragen. "Datei" in 
Anführungzeichen weil tail diese Zeilen auf einen Filedescriptor 
schreibt auch wenn dies nicht zwingend in einer echten Datei im 
Dateisystem mündet (zB. stdout, /dev/null, u.A.)

tail ist nicht gemacht um eine (log-)Datei auf n Zeilen begrenzt zu 
halten.
Resp. nur über den Umweg "neue Datei anlegen, alte Datei löschen, 
umbenennen", was aber nur funktioniert wenn das die Logdatei schreibende 
Programm (hier Synergy) den alten filedescriptor aufgibt und auf den 
neuen umschwenkt oder über eine Abstraktionszwischendingsda geht.

[Johannes S. (Gast)]

welche synergy Instanzen sind denn bei dir gestartet, was liefert

ps -Af | grep synergy

?

Joachim B. schrieb:
> also ehrlich da bleibe ich lieber bei Synergy 1.4.15 oder so

ja, viel Neues kann ich in V2 auch nicht finden. Ich hatte das Promo 
Angebot von 19$ angenommen, da ich das Tool gerne und oft nutze fand ich 
das fair, 49$ wäre mir auch hart an der Schmerzgrenze (für eine Beta 
Version!). Und die totale 'Vereinfachung' (weglassen der GUI mit den 
Einstellungen) finde ich auch nicht so prickelnd. Es gibt eine config 
datei in der man vielleicht etwas ändern kann, man weiss aber nicht ob 
das wieder überschrieben wird. Jetzt habe ich noch festgestellt das die 
deutschen Tasten keine Codes liefern wenn ich im RPi Terminal etwas 
eingeben will.
Eine Änderung ist das man den Server im Betrieb wählen kann, wenn also 
ein anderer Rechner auch eine Tastatur/Maus hat kann man den einfach zum 
Server klicken. Aber das brauche ich eigenlich nicht...
Der Grund auf V2 zu wechseln war ja das bei mir ein Kern auf 100% 
hochging nachdem der Server sich entfernt und wieder eingesetzt wurde. 
Wenn das bei dir nicht passiert würde ich auch nicht wechseln.

[DPA (Gast)]

Kommandozeile vor dem Frühstück für Alle! schrieb:
> DPA schrieb:
>> Joachim B. schrieb:
>>> funktioniert, aber kaum lasse ich das als cronjob laufen funktioniert es
>>> nicht
>>
>> Dann überprüfe/setze die PATH, das current working directory und die
>> Shell. Am besten packt man das ganze in ein Script in /usr/local/bin/
>> und ruft dann in cron nur das Script auf.
>
> Das ist unsichere Praxis. Scripte als root welche unbeaufsichtigt laufen
> sollen besser ausgeschriebene Pfade zu den Programme verwenden, ggfs.

Schon klar, dazu sage ich ja auch nichts. Trotzdem sollte man es an 
einen sinnvollen Ort wie /usr/local/bin/ ablegen, auch wenn man es 
ausschreibt. Und sobald man den PATH explizit gesetzt hat, kann man auch 
sonst da nichts mehr manipulieren.

[Andrew T. (marsufant)]

Joachim B. schrieb:
> funktioniert, aber kaum lasse ich das als cronjob laufen funktioniert es
> nicht, selbst nicht mit stop service und start service oder mit kill
> synergyc und nach der Dateimanipulation wieder mit Neustart

Weil es unter cron nicht die root-Berechtigung hat. Das  mußt Du cron 
mitgeben.

>> Du mußt schon eigene Arbeit invertieren.

> mach ich seit einer Woche,

tja, exakt das ist das Problem.

> tail -100

Nimm stattdessen   logrotate

[Joachim B. (jar)]

Andrew T. schrieb:
> Weil es unter cron nicht die root-Berechtigung hat. Das  mußt Du cron
> mitgeben.

das hatte ich gemacht!

Kommandozeile vor dem Frühstück für Alle! schrieb:
> tail ist ein Hilfsmittel um von einer gegebenen Datei nur max. die n
> letzten Zeilen in eine neue "Datei" zu übertragen. "Datei" in
> Anführungzeichen weil tail diese Zeilen auf einen /Filedescriptor/
> schreibt auch wenn dies nicht zwingend in einer echten Datei im
> Dateisystem mündet (zB. stdout, /dev/null, u.A.)
>
> tail ist nicht gemacht um eine (log-)Datei auf n Zeilen begrenzt zu
> halten.
> Resp. nur über den Umweg "neue Datei anlegen, alte Datei löschen,
> umbenennen", was aber nur funktioniert wenn das die Logdatei schreibende
> Programm (hier Synergy) den alten filedescriptor aufgibt und auf den
> neuen umschwenkt oder über eine Abstraktionszwischendingsda geht.

auch das hatte ich gemacht,

1. synergyc kill
Kopie angelegt
grep mit überflüssigen Ausgaben zeilenweise entfernt
tail -100 angewandt
synergyc neu gestartet

vermutlich nur noch nicht in der richtigen Kombination

Ich denke auch es muss funktionieren, ist halt mühsam

[Andrew T. (marsufant)]

Joachim B. schrieb:
> das hatte ich gemacht!

1. Zeig mal hier wie dies exakt von Dir gelöst wurde. Viellicht ist da 
schon..


2. Ggfs. ist diese Seite für die dem Loggen innewohnende Logik für Dich 
hilfreiche:
https://www.digitalocean.com/community/tutorials/how-to-view-and-configure-linux-logs-on-ubuntu-and-centos

[Karl K. (karl2go)]

Joachim B. schrieb:
> ich habe jetzt einen Cronjob gestartet der jede Nacht um 2:00 Uhr die
> LOGs löscht, vermindert zwar nicht die Schreibbelastung auf der SD aber
> verhindert zumindest das Überlaufen.

Und Umbiegen?

Kannst Du den Pfad der Logdateien ändern? Dann lege eine Ramdisk / 
virtualles Verzeichnis an und lass sie dahin schreiben, dann per Cron 
löschen.

[35°C (Gast)]

me@box:$synergyc --version
synergyc 1.3.1, protocol version 1.3

O.K. bisl älter;

$synergyc --help
$synergys --help

....

Where log messages go depends on the platform and whether or not the
client is running as a daemon.


------

Die alten Versionen finden sich doch auf github?
vlt. gibts ja ggf. compile-options an denen man drehen kann.

[Joachim B. (jar)]

Andrew T. schrieb:
> Weil es unter cron nicht die root-Berechtigung hat. Das  mußt Du cron
> mitgeben.

das hatte ich gemacht!

Kommandozeile vor dem Frühstück für Alle! schrieb:
> tail ist ein Hilfsmittel um von einer gegebenen Datei nur max. die n
> letzten Zeilen in eine neue "Datei" zu übertragen. "Datei" in
> Anführungzeichen weil tail diese Zeilen auf einen /Filedescriptor/
> schreibt auch wenn dies nicht zwingend in einer echten Datei im
> Dateisystem mündet (zB. stdout, /dev/null, u.A.)
>
> tail ist nicht gemacht um eine (log-)Datei auf n Zeilen begrenzt zu
> halten.
> Resp. nur über den Umweg "neue Datei anlegen, alte Datei löschen,
> umbenennen", was aber nur funktioniert wenn das die Logdatei schreibende
> Programm (hier Synergy) den alten filedescriptor aufgibt und auf den
> neuen umschwenkt oder über eine Abstraktionszwischendingsda geht.

auch das hatte ich gemacht,

1. synergyc kill
Kopie angelegt
grep mit überflüssigen Ausgaben zeilenweise entfernt
tail -100 angewandt
synergyc neu gestartet

im autostart
/home/pi/.aufraeumen.sh

#!/bin/bash
     
killall synergyc >null
sleep 1
sudo cp /var/log/debug /var/log/debug_save
sudo su -c "grep -v "Synergy" /var/log/debug_save | tail -n750  > /var/log/debug_save2"
sudo rm /var/log/debug_save
sudo mv /var/log/debug_save2 /var/log/debug

sudo cp /var/log/daemon.log /var/log/daemon.log_save
sudo su -c "grep -v "Synergy" /var/log/daemon.log_save | tail -n750  > /var/log/daemon.log_save2"
sudo rm /var/log/daemon.log_save
sudo mv /var/log/daemon.log_save2 /var/log/daemon.log

/usr/bin/synergyc --name raspbianPI3      192.168.178.20 
# ^ Pfad zu synergyc     ^ Name in liebe1 ^liebe1   
exit 0

vermutlich nur noch nicht in der richtigen Kombination

als cronjob hatte ich das auch versucht.
0 3   *   root   /home/pi/.aufraeumen.sh

Ich denke auch es muss funktionieren, ist halt mühsam

[Joachim B. (jar)]

Karl K. schrieb:
> Kannst Du den Pfad der Logdateien ändern?

das weiss ich eben noch nicht

> Dann lege eine Ramdisk /
> virtualles Verzeichnis an und lass sie dahin schreiben, dann per Cron
> löschen.

das war auch meine Idee

[Kommandozeile vor dem Frühstück vor Alle! (Gast)]

> im autostart /home/pi/.aufraeumen.sh
Oh Schreck: was ist das für eine verknorzte Denke!
- killall einfach so, dann aber sudo vor jeder Zeile UND als root laufen 
lassen?!?!????

#!/bin/bash

/bin/killall synergyc > /dev/null
/bin/sleep 1 

for pfn in /var/log/debug /var/log/daemon.log
do
   bck="${pfn}_bck"
   /bin/cat "${pfn}" ¦ /bin/grep -v 'Synergy' ¦ tail -j 750 > "${bck}"  \
   && /bin/rm "${pfn}"  \
   && /bin/mv "${bck}" "${pfn}"
done

/usr/bin/synergyc --name raspbianPI3 192.168.178.20
# ^ Pfad zu synergyc ^ Name in liebe1 ^liebe1
exit 0

ACHTUNG: auch ich clicke unter Windows daneben! "/bin/" muss auf DEINEM 
System nicht zwingend der richtige Pfad zu allen jeweiligen Programme 
sein!

[DPA (Gast)]

Falsche pipe ¦

[Karl K. (karl2go)]

Hm, einfach /var/log in eine Ramdisk umzubiegen scheint nicht so einfach 
zu gehen:

https://forum-raspberrypi.de/forum/thread/4046-var-log-in-eine-art-ramdisk-auslagern-weitere-optimierungen-bezgl-logs/

[Joachim B. (jar)]

Kommandozeile vor dem Frühstück vor Alle! schrieb:
> Oh Schreck: was ist das für eine verknorzte Denke!
> - killall einfach so, dann aber sudo vor jeder Zeile UND als root laufen
> lassen?!?!????

das war ein kleiner Ausschnitt von allem was ich in den letzten Tagen 
versucht hatte, natürlich im cronjob als root ohne SUDO!

manno, ich habe soviel probiert und nicht jeden Schritt akribisch 
dokumentiert, meine Restlebenszeit ist endlich und ich bin KEIN 
Buchhalter!

Karl K. schrieb:
> Hm, einfach /var/log in eine Ramdisk umzubiegen scheint nicht so einfach
> zu gehen:

zumindest habe ich Lesestoff gefunden, aber so weit bin ich noch nicht



http://www.kriwanek.de/index.php/de/raspberry-pi/265-ram-disk-auf-raspberry-pi-einrichten
RAM-Disk auf Raspberry Pi einrichten

Um bei Messdaten die Schreibzugriffe auf die SD-Card zu minimieren, kann 
eine kleine RAM-Disk eingerichtet werden.
Installation

Als Benutzer "pi" über SSH anmelden und folgende Kommandos eingeben:

Zuerst wird ein Mountpoint für die RAM-Disk erzeugt:

sudo mkdir /mnt/RAMDisk

Für die RAM-Disk muß die Filesystem Table angepasst werden:

sudo nano /etc/fstab

Einfügen dieser Zeile am Ende der Datei:

tmpfs /mnt/RAMDisk tmpfs nodev,nosuid,size=4M 0 0

Die Größe wird über den Parameter "4M" auf 4 MB festgelegt. Jetzt 
montiert man alle Filesysteme über:

sudo mount -a

Der Erfolg lässt sich mit Diskfree überprüfen:

df

Es sollte dann ein Eintrag mit der RAM-Disk zu finden sein:

Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 15071704 2734624 11674436 19% /
/dev/root 15071704 2734624 11674436 19% /
devtmpfs 218620 0 218620 0% /dev
tmpfs 44580 236 44344 1% /run
tmpfs 5120 0 5120 0% /run/lock
tmpfs 89140 0 89140 0% /run/shm
/dev/mmcblk0p1 57288 19712 37576 35% /boot
tmpfs 4096 0 4096 0% /mnt/RAMDisk

Jetzt ist nur noch zu prüfen, ob dies auch nach einem Reboot 
funktioniert:

sudo reboot

Mit Diskfree sollte jetzt die RAM-Disk wieder zu finden sein.
Weiteres Vorgehen

Jetzt ist zu testen, ob man Verzeichnisse und Dateien anlegen kann:

cd /mnt/RAMDisk

sudo mkdir testvz1

sudo mkdir testvz2

sudo touch file1

cd testvz1

sudo touch file2

Der "sudo"-Befehl wird benötigt, weil das Dateisystem 'root' gehört. 
Anschließend kann man mit

ls -al

ansehen, ob es funktioniert hat. Nach

sudo reboot

sind alle Verzeichnisse und Dateien verschwunden. Man muss sie also 
immer nach einem Reboot anlegen bzw. hineinkopieren.


Eigentums- und Zugriffsrechte

Mit dem Dateisystem der RAM-Disk kann man genauso umgehen wie mit dem 
einer SD-Card oder Harddisk. Die Eigentümerschaft wird mit

sudo chown pi:pi /mnt/RAMDisk

auf den Benutzer 'pi' und die Gruppe 'pi' umgestellt. Zugriffsrechte 
können mit

sudo chmod -R 760 /mnt/RAMDisk

geändert werden.


Weitere Infos

http://www.forum-raspberrypi.de/Thread-tutorial-var-log-in-eine-art-ramdisk-auslagern-weitere-optimierungen-bezgl-logs

http://www.domoticz.com/wiki/Setting_up_a_RAM_drive_on_Raspberry_Pi

[DPA (Gast)]

Nicht nur Probieren. Fehlerursache finden, verstehen und beheben. Nur 
mit Probieren kommt man nirgendwo hin.

[Kommandozeile vor dem Frühstück für Alle! (Gast)]

DPA schrieb:
> Falsche pipe ¦

'droid on-screen Keyboard... Keine andere da :'(

[Joachim B. (jar)]

DPA schrieb:
> Nicht nur Probieren. Fehlerursache finden, verstehen und beheben. Nur
> mit Probieren kommt man nirgendwo hin.

sage das mal den "Linuxexperten" die mich tatkräftig unterstützen.
In der Theorie sind ja viele Spitze, nur wenns konkret wird schwächeln 
viele, liegt aber nur an den verschiedenen Distris :)

[Kommandozeile vor dem Frühstück für Alle! (Gast)]

Joachim B. schrieb:
> Kommandozeile vor dem Frühstück vor Alle! schrieb:
>> Oh Schreck: was ist das für eine verknorzte Denke!
>> - killall einfach so, dann aber sudo vor jeder Zeile UND als root laufen
>> lassen?!?!????
>
> das war ein kleiner Ausschnitt von allem was ich in den letzten Tagen
> versucht hatte, natürlich im cronjob als root ohne SUDO!

Hier bekommen wir nur das zu sehen was Du postest, damit arbeitest Du an 
deinem persönlichen Image und an dem Eindruck den wir von Dir und Deiner 
Arbeitsweise aufbauen.

> manno, ich habe soviel probiert und nicht jeden Schritt akribisch
> dokumentiert, meine Restlebenszeit ist endlich und ich bin KEIN
> Buchhalter!
Dann lebe mit der schlechten Lernkurve, welche Du so kratzt.
Anders als bei GUIs ist es ausgerechnet bei CLI etliche Grössenordnungen 
einfacher die eigenen Tätigkeiten exakt zu protokollieren, dokumentieren 
und reproduzieren.
Aber wo der Wille schwach: alles runter den Bach...

[Egon D. (Gast)]

Joachim B. schrieb:

> DPA schrieb:
>> Nicht nur Probieren. Fehlerursache finden, verstehen
>> und beheben. Nur mit Probieren kommt man nirgendwo hin.
>
> sage das mal den "Linuxexperten" die mich tatkräftig
> unterstützen. In der Theorie sind ja viele Spitze, nur
> wenns konkret wird schwächeln viele, liegt aber nur an
> den verschiedenen Distris :)

Langsam nimmt es bizarr-pathologische Züge an.

1.
Du wurdest MEHRFACH darauf hingewiesen, dass "tail"
NICHT die Datei selbst kürzt.
"tail" liefert nur das letzte Stück der Datei zurück ,
damit man sich beispielsweise die letzten x Zeilen
anzeigen lassen kann.

Wie harthörig muss man sein, um trotzdem IMMER WIEDER
völlig unsinnig mit "tail" herumzumurksen?

2.
Ich hatte vorgeschlagen, die Log-Ausgaben mittels eines
Links auf /dev/null umzuleiten. Ich hätte ebensogut mit
einem schwarzen Loch oder einem schalltoten Raum reden
können -- das Echo wäre genauso gewesen.
Wahrscheinlich ist der Vorschlag deshalb inakzeptabel,
weil er das Problem -- zwar etwas rustikal, aber
immerhin -- tatsächlich löst .
Das geht ja gar nicht. Da hat man ja keinen Grund zum
Stänkern mehr.

[Konrad S. (maybee)]

Ein cron-Job hat (fast) kein Environment. Man tut gut daran, im Script 
zuerst PATH zu setzen und zu exportieren.

Das Löschen einer Datei, die noch geöffnet ist (z.B. vom 
*syslogd-Daemon), führt nicht dazu, dass der Speicherplatz freigegeben 
wird. Erst wenn das letze Filehandle für eine Datei geschlossen wird, 
wird auch der Speicherplatz einer gelöschten Datei freigegeben.

Wer eine Datei geöffnet hat, verrät einem fuser oder lsof - 
vorausgesetzt, man hat die nötigen Zugriffsrechte oder ist root.

Ein *syslogd-Daemon reagiert auf ein HUP-Signal durch Schließen aller 
Logfiles (und neu einlesen und abarbeiten seiner Konfiguration).

[Joachim B. (jar)]

Egon D. schrieb:
> Langsam nimmt es bizarr-pathologische Züge an.
>
> 1.
> Du wurdest MEHRFACH darauf hingewiesen, dass "tail"
> NICHT die Datei selbst kürzt.
> "tail" liefert nur das letzte Stück der Datei zurück ,
> damit man sich beispielsweise die letzten x Zeilen
> anzeigen lassen kann.

ach und das war mir bewusst und kann in eine neue Datei umgeleitet 
werden was ich auch zeigte

> Wie harthörig muss man sein, um trotzdem IMMER WIEDER
> völlig unsinnig mit "tail" herumzumurksen?

???
da bemerke ich nur

Egon D. schrieb:
> Da hat man ja keinen Grund zum
> Stänkern mehr.

mir kommt es gerade so vor als wenn du stänkern willst?

wenn du dem Thread nicht folgst und das Geschriebene nicht verstehst ist 
es nicht meine Schuld

sudo  sh -c  'mv  -v  /var/log/debug  /tmp/debug.orig  \
                &&  grep  -v Synergy  |  tail -n300  \
                > /var/log/debug'

ich erkenne genau das was mir schon öfter vorgeschlagen wurde, nicht nur 
hier

/var/log/debug nach /tmp/debug.orig kopieren
und durch grep jagen und zeilenweise das Auftreten von Synergy entfernen
&&  grep  -v Synergy  |  tail -n300
danach ein tail anwenden und mittels PIPE ausgeben auf
/var/log/debug

So und nun noch die ganzen Möglichkeiten durchspielen, wenn nicht 
spezifiziert wird

1. klappt das einem Sys das unterzujubeln? oder muss man erst
2. den Dienst beenden?
3. geht das mit kill oder mit stop?
vieles wurde eben nicht erwähnt und ich denke ohne diese Details wird 
der Weg nicht klappen, was ich mehrfach erlebte.

Ich kann hier seitenweise zeigen was mir vorgeschlagen wird, entweder 
bin ich zu blöd für C&P oder die Vorschläge waren nur theoretischer 
Natur und funktionieren grundsätzlich nicht, suche es dir aus!

hier hatte ich halt bessere Hilfe und auch Erfolg.
http://forum.nas-forum.org/index.php?page=Thread&threadID=277

[Egon D. (Gast)]

Joachim B. schrieb:

> mir kommt es gerade so vor als wenn du stänkern
> willst?

Nicht unbedingt, nein.

Mich haben nur Deine unangemessenen Spitzen gegen die
"Fachleute" geärgert. Viele hier kennen sich WIRKLICH
aus, und sie versuchen WIRKLICH, Dir zu helfen.

Du machst es ihnen aber verhältnismäßig schwer.


> wenn du dem Thread nicht folgst und das Geschriebene
> nicht verstehst ist es nicht meine Schuld

Ich bin soweit gefolgt, dass Du das Logging drosseln willst,
weil Du Deine SSD nicht unbedingt kaputtschreiben willst.
Verstehe ich.


> sudo  sh -c  'mv  -v  /var/log/debug  /tmp/debug.orig  \
>                 &&  grep  -v Synergy  |  tail -n300  \
>                 > /var/log/debug'
>
> ich erkenne genau das was mir schon öfter vorgeschlagen
> wurde, nicht nur hier

Mir ist nicht klar, was das bringen soll. Diese Kommando-
zeile kürzt EINMALIG das Logfile. Das ist das, was Du
willst?

Außerdem würde ich nicht voraussetzen, dass das so
funktioniert. Ich wäre mir nicht sicher, was passiert,
wenn man versucht, am Prozess vorbei in das noch
geöffnete Logfile zu schreiben.

Ich verstehe also den Sinn nicht ganz... die Aktion
würde zwar das Log kürzen, aber nicht verhindern, dass
der Prozess in Zukunft immer noch genauso übermäßig
ausführlich loggt.

[Joachim B. (jar)]

Egon D. schrieb:
>> mir kommt es gerade so vor als wenn du stänkern
>> willst?
>
> Nicht unbedingt, nein.

gut also peace

Egon D. schrieb:
> Mich haben nur Deine unangemessenen Spitzen gegen die
> "Fachleute" geärgert.

bin frustriert weil es nicht funktioniert, besonders ärgern mich die 
Fachleute die mir Blödheit unterstellen sich aber im Einzelfall wenns 
kompliziert wird schnell vom Acker machen und da mir das öfter passiert 
ist liegt meine Toleranzschwelle wohl zu niedrig.

Du hast ja auch ein wenig rumgemault:

Egon D. schrieb:
> Du wurdest MEHRFACH darauf hingewiesen, dass "tail"
> NICHT die Datei selbst kürzt.
> "tail" liefert nur das letzte Stück der Datei zurück ,
> damit man sich beispielsweise die letzten x Zeilen
> anzeigen lassen kann.
>
> Wie harthörig muss man sein, um trotzdem IMMER WIEDER
> völlig unsinnig mit "tail" herumzumurksen?

hattest du die PIPE Umlenkung von tail in die neue Datei nicht bemerkt?

wenn tail -100 die letzten 100 Zeilen ausgibt wie du schreibst dann ist 
es doch logisch das ich die per pipe umlenken kann in eine neue Datei 
sogar ins alte LOG (nur das das bis jetzt eben nicht funktionierte), 
damit erreiche ich doch das Gewünschte.

Einige schlugen Ausgaben mit pipe nach nul vor >nul oder >null

funktionierte auch nicht aber was ich fand war eine neue Datei Namens 
nul oder null die ich an dieser Stelle noch nie gesehen hatte.

Manchmal ist Linux echt zickig, dabei weiss ich schon seit Jahren das 
man unnötige Ausgaben in nirwana schicken kann auch mit pipe nach nul

nur scheint mir das es an den Distris liegt wie das geschrieben wird 
oder an welcher Stelle es nicht wirkt?

oder heisst es immer /dev/nul und ohne /dev gehts eben nicht?

Ist das nun meine Unwissenheit oder Schlampigkeit vom Experten wenn mir 
>nul vorgeschlagen wird statt >/dev/nul?

[Johannes S. (Gast)]

ich kann den Link auf /dev/null nicht mehr ausprobieren weil mein System 
mittlerweile kaputt ist. Ich hatte Wolfram über die GUI deinstalliert, 
apt-get update/upgrade hat es versucht wieder zu installieren. Beim 
auspacken/installieren des GB grossen Paket hat sich das System 
aufgehängt und jetzt startet es nicht mehr :-( SDC als Festplatte ist 
einfach nur Kacke.

[Bernd K. (prof7bit)]

Hier herrscht ja das reine Chaos. Wäre es nicht sinnvoller da etwas 
systematischer vorzugehen?

Ich gehe immer folgendermaßen vor:

* Tür zu machen (Ruhe)
* Ist-Zustand erfassen und verstehen(!)
  Dies beinhaltet das Ermitteln welche Komponenten sind daran beteiligt,
  in welcher Weise, welche Aufgaben haben die, wo werden die
  konfiguriert, wie SIND die momentan konfiguriert, evtl. durch gezielte
  Eingriffe in die Konfiguration testen ob man wirklich verstanden hat
  was das bewirken soll, ob es das bewirkt was man denkt, solange bis
  man zu dem Punkt kommt wo man ausruft: "na logisch tritt das Problem
  auf, muss es ja wenn das so ist!"
* Nachdenken (Normalerweise hat man an diesem Punkt eine oder mehrere
  Lösungsmöglichkeiten oder manchmal weiß man jetzt auch sicher daß
  man leider gar keine hat)
* Lösung implementieren und erwarteten Erfolg testen, bei Fehlschlag
  zurück zu Schritt 2 denn irgendwas hat man noch nicht verstanden
  oder falsch verstanden. Wenn es geht, weiter im nächsten Schritt.

* Tür wieder öffnen und ne Runde an der frischen Luft drehen

* Entwarnung im Forum geben und gewählte Lösung beschreiben (da man
  gründlich vorgegangen ist hat man entweder die optimale Lösung
  gefunden oder man kann zumindest schlüssig begründen warum man es
  so gemacht hat und nicht anders)

Die letzten 2 Schritte habe ich durch Leerzeilen voneinander abgesetzt, 
dies symbolisiert daß jetzt der Druck raus ist und alles wieder schön 
gemütlich geht.

[17°C sighs (Gast)]

Joachim B. schrieb:

> Manchmal ist Linux echt zickig, dabei weiss ich schon seit Jahren das
> man unnötige Ausgaben in nirwana schicken kann auch mit pipe nach nul
>

Was soll daran zickig sein, eher Defizite im Grundverständnis.

> nur scheint mir das es an den Distris liegt wie das geschrieben wird
> oder an welcher Stelle es nicht wirkt?




-null- ist eine virtuelle Gerätedatei, ein devicefile.
Die findet man dort wo sich devicefiles tummeln unter -dev-

/dev/null

Weshalb prüfst du nicht einfach was du vor dir hast?!

ls /dev |grep "^nu", find /dev -iname 'nu*', ...


root@box:$ls /dev |grep '^nu'
null

root@box:$find /dev -iname "nu*"
dev.udev/names/null
/dev/null


Du willst wissen ob es bei dir einen Link Namens "nul" auf /dev/null 
gibt dann guck doch einfach nach, such bspw nach allen sybolischen links 
die auf -null- verweisen.

find / -lname /dev/null

wenn da nichts hochkommt dann gibts bei deinem System das eben nicht.
Richte es eben schnell ein wenn du es haben willst.


ln -s /dev/null nul

find . -lname /dev/null
./nul

Oder nenns gleich lognull oder wie immer du magst und gib dem link dem 
synergy als logfile, sollt aber auch direkt mit /dev/null funktionieren 
denn das ist ja auch nur eine (geräte)Datei.


>
> oder heisst es immer /dev/nul und ohne /dev gehts eben nicht?
>
> Ist das nun meine Unwissenheit oder Schlampigkeit vom Experten wenn mir
>>nul vorgeschlagen wird statt >/dev/nul?


Damit es funktioniert brauchts doch zwei Dinge;
Die Datei muss existieren und der Weg zu ihr bekannt sein.

Das hat mit linux selber mal eher wenig zu tun.
Und ob einer das ruckzuck in der shell erledigt oder sich in 
Windowsmanier einen Dateimanager bemüht ebensfalls nicht.

[Sheeva P. (sheevaplug)]

Joachim B. schrieb:
> bin frustriert weil es nicht funktioniert, besonders ärgern mich die
> Fachleute die mir Blödheit unterstellen sich aber im Einzelfall wenns
> kompliziert wird schnell vom Acker machen und da mir das öfter passiert
> ist liegt meine Toleranzschwelle wohl zu niedrig.

Es macht es den Fachleuten nicht gerade einfach, wenn Du a) nicht genau 
beschreibst, was Du eigentlich vorhast, b) nicht richtig zuhörst und c) 
Vorschläge verschiedener Leute wild mit einander vermengst.

> hattest du die PIPE Umlenkung von tail in die neue Datei nicht bemerkt?
>
> wenn tail -100 die letzten 100 Zeilen ausgibt wie du schreibst dann ist
> es doch logisch das ich die per pipe umlenken kann in eine neue Datei
> sogar ins alte LOG (nur das das bis jetzt eben nicht funktionierte),
> damit erreiche ich doch das Gewünschte.

Nein. Mit einer Pipe leitest Du einen Datenstrom -- standardmäßig ist 
das die Standard-Ausgabe (stdout) -- in die Standardeingabe (stdin) 
eines weiteren Prozesses um.

grep -v Synology /var/log/debug | tail -n 300 | less

In diesem Beispiel liest der grep(1)-Aufruf die Datei /var/log/debug und 
gibt alle Zeilen, in denen der String "Synology" nicht vorkommt, auf 
seine Standardausgabe (stdout) aus. Die erste Pipe (oder genauer: die 
Shell, in welcher der Befahl abgesetzt wurde) liest diese 
Standardausgabe und leitet sie auf die Standardeingabe des zweiten 
Programms tail(1) um, die zweite Pipe leitet die Ausgabe von "tail -n 
300" (Kurzform: "tail -300") auf den Viewer less(1) um. Keiner der 
Befehle ändert allerdings etwas an der Datei /var/log/debug -- grep(1) 
liest diese Datei nur, und die beiden anderen Befehle wissen gar nichts 
von der Datei, sondern erhalten ihre Daten über die Standardeingabe 
stdin.

Programme, die ihre Daten über die Standardeingabe entgegennehmen und 
die verarbeiteten Daten auf die Standardausgabe ausgeben, sind in der 
UNIX-Welt so weit verbreitet, daß sich der Fachausdruck "Filter" dafür 
etabliert hat. Viele Programme, darunter etwa sort(1), grep(1), cat(1) 
oder auch tail(1) arbeiten automatisch als Filter, wenn keine 
Eingabedatei angegeben wurde. Daher besteht funktional kein Unterschied 
zwischen den Befehlen:

grep -v Synology /var/log/debug

und

cat /var/log/debug | grep -v Synology

Technisch betrachtet gibt es allerdings sehr wohl einen Unterschied: im 
ersten Fall öffnet grep(1) die Datei und liest sie, um zweiten Fall 
öffnet cat(1) die Datei, liest sie, und gibt sie auf der Standardausgabe 
stdout aus, woraufhin die Pipe (bzw. die Shell) die Daten auf die 
Standardeingabe stdin des Programms grep(1) schreibt. Im zweiten Fall 
arbeitet grep(1) als Filter, im ersten nicht.

> Einige schlugen Ausgaben mit pipe nach nul vor >nul oder >null

">" ist keine Pipe, sondern eine Ausgabeumleitung auf eine Datei. Dabei 
gilt es, ein paar Kleinigkeiten zu beachten: wie auch bei der Pipe wird 
diese Ausgabeumleitung von der Shell ausgeführt, und zwar zuerst. Wenn 
die Ausgabedatei bereits existiert, wird sie geleert, wenn sie nicht 
existiert, wird sie angelegt. Eine Ausgabeumleitung auf ">nul" erzeugt 
bzw. kürzt also die Datei "nul" im aktuellen Arbeitsverzeichnis, und, 
ganz wichtig: dieser Schritt erfolgt zu allererst, bevor irgendein 
Programm gestartet wird und irgendeine Ausgabe erzeugen kann.

Eine weiter Form der Ausgabeumleitung ist ">>". Dabei wird die Datei wie 
zuvor erzeugt, aber wenn sie bereits vorhanden ist, wird die Ausgabe der 
aufzurufenden Befehle an die betreffende Datei angehängt. Auch dabei 
erfolgt das Öffnen der Datei zuerst, bevor ein Programm aufgerufen wird.

Natürlich existiert auch eine Eingabeumleitung "<", welche die 
angegebene Datei liest und auf die Standardeingabe stdin des 
aufgerufenen Programms schreibt. Darum hätte das letzte Beispiel auch 
als

cat < /var/log/debug | grep -v Synology

oder sogar als

grep -v Synology < /var/log/debug

geschrieben werden können; in diesen Beispielen hätte die Shell die 
Datei geöffnet und ihren Inhalt im oberen Beispiel an das Programm 
cat(1) und im unteren Beispiel an das Programm grep(1) übergeben, und 
zwar über deren jeweilige Standardeingabe stdin. Das ergibt hier zwar 
keinen Sinn, da sowohl cat(1) als auch grep(1) direkt auf Dateien 
arbeiten können, aber bei anderen Programmen kann das durchaus sinnvoll 
sein.

> Manchmal ist Linux echt zickig

Nein, überhaupt nicht. Wenn man diese Dinge gelernt und verstanden hat, 
funktionieren sie absolut vorhersehbar und mit einander kombinierbar.

> nur scheint mir das es an den Distris liegt wie das geschrieben wird
> oder an welcher Stelle es nicht wirkt?

Nein, mit den verschiedenen Distributionen hat das nichts zu tun. Diese 
Dinge funktionieren in jeder Bourne-Again-Shell bash(1), die heute alle 
verbreiteten Distributionen als Standard-Shell benutzen, genau gleich.

> Ist das nun meine Unwissenheit oder Schlampigkeit vom Experten wenn mir
>>nul vorgeschlagen wird statt >/dev/nul?

Sowohl, als auch.


So, nachdem wir diese Dinge und ein paar Fachbegriffe geklärt haben, 
gibt es da noch einen weiteren Punkt, nämlich die Arbeit mit offenen 
Dateien. Im Gegensatz zum vorher gesagten können die Programme eines 
Linux-Systems nämlich gar keine Dateien öffnen, sondern nur den 
Systembefehl open(2) an den Betriebssystemkern (also das eigentliche 
Linux) schicken. Der gibt dem aufrufenden Programm dann einen 
Dateihandle zurück, auf den das Programm dann mit zum Beispiel den 
Systembefehlen read(2), write(2) oder close(2) arbeiten kann.

Wenn die Datei umbenannt wird, wird nur die Metainformation "Dateiname" 
im Dateisystem geändert. Sollte ein Prozeß (zum Beispiel ein Logdaemon) 
die Datei zu diesem Zeitpunkt geöffnet haben, also einen aktiven 
Dateihandle darauf halten, wird der weder geschlossen noch geändert. Das 
heißt, der Prozeß kann trotzdem weiterhin auf der Datei arbeiten, sie 
lesen und hineinschreiben, auch wenn der Rest des Systems die Datei nur 
unter ihrem neuen Dateinamen ansprechen kann.

Dasselbe gilt, wenn eine Datei gelöscht wird, auf die ein Prozeß noch 
ein aktives Dateihandle hat. Dann kann der Prozeß sein geöffnete Datei 
weiter bearbeiten, und die wirkliche Löschung der Datei inklusive 
Freigabe des von ihr belegten Festplattenplatzes erfolgt erst dann, wenn 
der letzte Prozeß die Datei geschlossen hat.

Was passiert also, wenn Du den Befehl

grep -v Synology /var/log/debug > /var/log/debug.save

eingibst, passiert Folgendes: erst erkennt die Shell die 
Ausgabeumleitung und weist das Betriebssystem an, die Datei 
"/var/log/debug.save" entweder anzulegen, wenn diese nicht vorhanden 
ist. Wenn die Datei vorhanden ist, wird ihr Inhalt auf 0 Bytes gekürzt. 
Dann startet die Shell den Befehl grep(1), der nun den 
Betriebssystemkernel anweist, die Datei "/var/log/debug" zum Lesen zu 
öffnen und ein Dateihandle dafür bereitzustellen. grep(1) weist 
daraufhin das Betriebssystem an, mit dem Systembefehl read(1) aus der 
Datei zu lesen und die gelesenen Inhalte an grep(1) weiterzugeben. 
Daraufhin unterdrückt grep(1) die Ausgabe aller Zeilen heraus, die den 
Term "Synology" enthalten, und gibt die übrigen auf seiner 
Standardausgabe aus.

Hättest Du stattdessen den Befehl

grep -v Synology /var/log/debug > /var/log/debug

eingegeben, wo dürfte Dir nach dem vorher Gesagten mittlerweile klar 
sein, warum dann zuerst die Datei von der Shell zum Schreiben geöffnet 
und dabei auf 0 Bytes gekürzt wird -- so daß dann nichts mehr in der 
Datei steht, das grep(1) lesen könnte.

Alle diese Dinge mögen für Einsteiger, die aus anderen Systemwelten 
kommen, etwas verwirrend sein. Aber sie sind unter allen mir bekannten 
UNIXen seit Jahrzehnten der Standard, ermöglichen dem Könner viele 
Möglichkeiten viele nette Arbeitserleichterungen, und einige dieser 
Eigenschaften sind für die Multiuser-Fähigkeiten von UNIX-Systemen 
essentiell.


Gut, kommen wir noch einmal auf Dein ursprüngliches Problem zurück. Wo 
ist Dein Problem? Kannst Du mir das bitte noch einmal ausführlich 
erklären, von Anfang an und von Grund auf?

[Joachim B. (jar)]

Sheeva P. schrieb:
> Gut, kommen wir noch einmal auf Dein ursprüngliches Problem zurück. Wo
> ist Dein Problem? Kannst Du mir das bitte noch einmal ausführlich
> erklären, von Anfang an und von Grund auf?

gerne und DANKE


also das sonst gut funktionierende synergy(c) macht debug Ausgaben im 
DIR
/var/log

allerdings auch wenn der Server down ist schreibt es debug voll bis eine 
SD mit dem OS voll ist, auch noch an anderen Stellen gibt es dann 
Synergy Einträge

also, mein Wunsch, alle Einträge in den LOG Dateien die das Wort Synergy 
tragen zu löschen, die ganze Zeile.

Damit die LOGs nicht unendlich groß werden (SD Speicher endlich) nur die 
letzten 100-300 Zeilen vorrätig zu halten, könnte ja sein das man doch 
mal nachsehen möchte. Ausserdem sollen keine komprimierten Sicherungen 
der LOGs angelegt werden .gz oder .old was auch passiert

Da SD Karten nicht unendlich viele Schreibcyclen vertragen wäre optimal 
eine Ramdisk für die LOG Dateien sinnvoll und nur 1x täglich oder 
wöchentlich ein Übertrag auf die SD sinnvoll.

[Sheeva P. (sheevaplug)]

Joachim B. schrieb:
> also das sonst gut funktionierende synergy(c) macht debug Ausgaben im
> DIR /var/log

So weit, so gut, denn dort gehören solche Ausgaben natürlich hin.

> allerdings auch wenn der Server down ist schreibt es debug voll bis eine
> SD mit dem OS voll ist, auch noch an anderen Stellen gibt es dann
> Synergy Einträge

Ok, ich kenne die Software leider nicht, deswegen hätte ich da ein paar 
Fragen. Was genau macht diese Software? Der Manpage von Debian Stretch 
entnehme ich, daß es um einen "mouse/keyboard sharing client" ist. Ich 
vermute einmal, daß man damit mit einer Tastatur+Maus mehrere Computer 
bedienen kann, ist das korrekt?

Benutzt Du die Version, die mit Raspbian Stretch ausgeliefert wird?

Weiterhin würde mich interessieren, wie genau diese Software gestartet 
wird. Besitzt sie ein eigenes systemd-Unitfile, ein SysV-Startscript, 
oder wird sie von einem anderen Prozess gestartet?

Läßt sich die Software konfigurieren? Der Manpage entnehme ich, daß man 
ihr entweder mit "-l" oder "--log" eine Logdatei angeben kann, und daß 
sie auf den lokalen syslog-Daemon loggt, wenn sie als Daemon betrieben 
wird.

Muß die Software unter einer bestimmten oder gar unter einer 
privilegierten Benutzerkennung (root) laufen?

Außerdem stellt sich mir die Frage, ob diese Software dauerhaft laufen 
muß. Würde es ausreichen, sie dann zu starten, wenn der Benutzer 
eingeloggt ist?

Könnte die Verfügkeit des Servers möglicherweise periodisch geprüft 
werden die Software nur dann gestartet werden, wenn der Server verfügbar 
ist, und automatisch gestoppt werden, wenn das nicht der Fall ist?

Dann würde mich interessieren, wie groß Deine SD-Karte ist und wie weit 
sie belegt ist. Ist die möglicherweise ohnehin etwas knapp bemessen?

Je mehr Du mir über das System, seine Aufgaben, seine Umgebung die 
Software und Deinen Einsatzzweck sagen kannst, desto besser kann ich Dir 
helfen.

> also, mein Wunsch, alle Einträge in den LOG Dateien die das Wort Synergy
> tragen zu löschen, die ganze Zeile.

Schreibt die Software ihre eigenen Logdateien, oder loggt sie über 
rsyslogd bzw. journald?

> Damit die LOGs nicht unendlich groß werden (SD Speicher endlich) nur die
> letzten 100-300 Zeilen vorrätig zu halten, könnte ja sein das man doch
> mal nachsehen möchte. Ausserdem sollen keine komprimierten Sicherungen
> der LOGs angelegt werden .gz oder .old was auch passiert

Dazu müßtest Du logrotate(1) konfigurieren. Wenn Du mir Deine aktuelle 
Datei /etc/logrotate.conf zeigst, kann ich Dir sicherlich ein paar Tipps 
geben, wie Du das Gewünschte erreichen kannst. Im Allgemeinen sollte es 
reichen, alle "rotate"-Einträge auf 0 und alle "weekly", "monthly" et al 
auf "daily" zu setzen. Dann werden die Logdateien täglich rotiert und 
die alten werden nicht komprimiert, sondern weggeworfen, siehe dazu auch 
die Manpage "logrotate.conf".

Gibt es auf Deinem System das Verzeichnis "/var/log/journal/"?

> Da SD Karten nicht unendlich viele Schreibcyclen vertragen wäre optimal
> eine Ramdisk für die LOG Dateien sinnvoll und nur 1x täglich oder
> wöchentlich ein Übertrag auf die SD sinnvoll.

Du könntest /var/log als tmpfs(5) mounten, mußt Dich dann aber selbst um 
den wöchentlichen Übertrag kümmern -- und ebenso, wenn die Maschine 
einmal rebootet wird. Bei Abstürzen, Stromausfällen oä. sind Deine Logs 
dann aber weg, was besonders ärgerlich ist, wenn man die Fehlerursache 
herausfinden möchte. Eine bessere Alternative könnte es daher sein, auf 
einen anderen Host mit einer Festplatte oder ggf. auf eine eigene 
USB-Disk zu loggen.

[Joachim B. (jar)]

Sheeva P. schrieb:
> entnehme ich, daß es um einen "mouse/keyboard sharing client" ist. Ich
> vermute einmal, daß man damit mit einer Tastatur+Maus mehrere Computer
> bedienen kann, ist das korrekt?

ja

Sheeva P. schrieb:
> Benutzt Du die Version, die mit Raspbian Stretch ausgeliefert wird?

nein, ich weiss nicht welche Version mit stretch ausgeliefert wird, ich 
benutze jessiePIXEL und die Synergy Version seit wheezy

https://learn.adafruit.com/synergy-on-raspberry-pi/intro-what-is-synergy

sudo apt-get install synergy

Sheeva P. schrieb:
> Weiterhin würde mich interessieren, wie genau diese Software gestartet
> wird

nano /home/pi/.config/lxsession/LXDE-pi/autostart
@lxpanel --profile LXDE-pi
@pcmanfm --desktop --profile LXDE-pi
@xscreensaver -no-splash
@point-rpi
@xset s off
@xset -dpms
@xset s noblank
/home/pi/.startsynergy.sh

sudo nano /home/pi/.startsynergy.sh

#!/bin/bash
     
killall synergyc
sleep 1
/usr/bin/synergyc --name raspbianPI3      192.168.178.20
# ^ Pfad zu synergyc     ^ Name in liebe1 ^liebe1   
exit 0

sudo chmod 777 /home/pi/.startsynergy.sh

Sheeva P. schrieb:
> Schreibt die Software ihre eigenen Logdateien, oder loggt sie über
> rsyslogd bzw. journald?

synergy logt in debug, daemon, syslog

Sheeva P. schrieb:
> Wenn Du mir Deine aktuelle
> Datei /etc/logrotate.conf zeigst, kann ich Dir sicherlich ein paar Tipps
> geben, wie Du das Gewünschte erreichen kannst

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0660 root utmp
    rotate 1
}

# system-specific logs may be configured here

Sheeva P. schrieb:
> Gibt es auf Deinem System das Verzeichnis "/var/log/journal/"?

nope

Sheeva P. schrieb:
> sind Deine Logs
> dann aber weg, was besonders ärgerlich ist, wenn man die Fehlerursache
> herausfinden möchte. Eine bessere Alternative könnte es daher sein, auf
> einen anderen Host mit einer Festplatte

auf das NAS?

aber das macht auch jeden Montag um 2 Uhr ein reboot.

Mir wird immer wieder gesagt das Linux das nicht braucht, ABER wenn ich 
ins System vom Qnap schaue gibt es dort Meldungen das es lange nicht 
mehr neu gestartet wurde und es empfohlen ist, irgendwie ein 
Widerspruch?

Ich weiss aber das garbage collection irgendwie nicht mehr in ist, ich 
kenne das noch von früher, aber richtiges Aufräumen von Speicherlöchern 
klappt wohl nur theoretisch?

[Sheeva P. (sheevaplug)]

Ok, ich gehe auf Deinen Beitrag ein, wenngleich noch einige meiner 
Fragen offen sind und sich weitere stellen. Bevor Du etwas machst, sei 
bitte so lieb und beantworte alle meine Fragen. Und bitte sei so lieb 
und lies' alles, was ich schreibe, ich mache das ja nicht grundlos. 
Danke. ;-)

Joachim B. schrieb:
> Sheeva P. schrieb:
>> entnehme ich, daß es um einen "mouse/keyboard sharing client" ist. Ich
>> vermute einmal, daß man damit mit einer Tastatur+Maus mehrere Computer
>> bedienen kann, ist das korrekt?
>
> ja

Also, kurz gesagt: Du hast ein Synology NAS, einen RasPi, sowie noch 
einen Windows-Rechner, der vermutlich Deine primäre Arbeitsmaschine ist. 
Weiter vermute ich, daß sowohl der RasPi als auch Dein Windows-Rechner 
jeweils einen eigenen Monitor haben, zwischen denen Du dank des synergyc 
hin- und herwechseln kannst. Soweit ich weiß, haben die Synologies aber 
keine GUI, sondern nur ein Webfrontend, so daß der synergyc also dazu 
dient, von dem Windows-Rechner aus den RasPi zu bedienen. Ist das 
richtig?

> Sheeva P. schrieb:
>> Weiterhin würde mich interessieren, wie genau diese Software gestartet
>> wird
>
>

> nano /home/pi/.config/lxsession/LXDE-pi/autostart
> [...]
> /home/pi/.startsynergy.sh
>

Ah, also beim Login über den Autostart von LXDE. Das funktioniert 
natürlich nur dann, wenn Du Dich in den LXDE einloggst. Wenn Du 
möchtest, daß das auch dann funktioniert, wenn Du Dich ohne GUI 
einloggst, sind ~/.profile oder ~/.bashrc ein besserer Ort für diesen 
Aufruf.

> sudo nano /home/pi/.startsynergy.sh
>

> #!/bin/bash
> 
> killall synergyc
> sleep 1
> /usr/bin/synergyc --name raspbianPI3      192.168.178.20
> # ^ Pfad zu synergyc     ^ Name in liebe1 ^liebe1
> exit 0
>

> sudo chmod 777 /home/pi/.startsynergy.sh

Da das Skript vermutlich Deinem Benutzer gehört und auch nicht für Group 
und Others les-, beschreib- oder ausführbar sein muß, würde "chmod 700 
..." ohne sudo hier völlig ausreichen.

Nun, Du sagst, daß der synergyc nur dann wie wild loggt, wenn der 
"Server" nicht verfügbar ist. Ist mit "Server" Dein Synology NAS 
gemeint?

Wenn ja, könnten wir die Veranstaltung ein wenig umbauen, so daß das 
Skript nicht einfach nur stumpf den synologyc startet, sondern etwa so 
eine Logik implementiert (Pseudocode):

while True:
    if server_is_reachable():
        # start synologyc
        /usr/bin/synologyc --name raspbianPI3 192.168.178.20
    else:
        # stop synologyc
        /usr/bin/killall synologyc
    sleep 60

Damit würde das Programm alle sechzig Sekunden nachschauen, ob der 
Server verfügbar ist. Wenn ja, würde es den synologyc starten, und wenn 
nicht, würde es den synologyc stoppen. Da dieses Programm aber nie 
zurückkehrt, bevor Du Dich ausloggst, muß es mit einem abschließenden 
"&" aufgerufen (oder mit daemonize oä. gestartet) werden, damit es in 
den Hintergrund versetzt wird, sonst wird Dein Login blockiert.

Ansonsten könntest Du mal versuchen, in Dein .startsynergy.sh den 
Parameter für die Logdatei zu setzen und diese auf /dev/null umzubieten, 
wenn Du nie an den Logs Deines synologyc interessiert bist. Dazu müßtest 
Du die Zeile

/usr/bin/synergyc --name raspbianPI3      192.168.178.20

durch

/usr/bin/synergyc --name raspbianPI3 --log /dev/null 192.168.178.20

ersetzen.

> Sheeva P. schrieb:
>> Schreibt die Software ihre eigenen Logdateien, oder loggt sie über
>> rsyslogd bzw. journald?
>
> synergy logt in debug, daemon, syslog

Dann loggt die Software wohl über den rsyslogd(8).

> Sheeva P. schrieb:
>> Wenn Du mir Deine aktuelle
>> Datei /etc/logrotate.conf zeigst, kann ich Dir sicherlich ein paar Tipps
>> geben, wie Du das Gewünschte erreichen kannst
>
>

> # see "man logrotate" for details
>

Was mir auf den ersten Blick auffällt: die Komprimierung ist 
ausgeschaltet (Zeile "#compress"), weswegen die Logdateien bei der 
Rotation nicht komprimiert werden. Durch die Komprimierung kann man da 
aber häufig mehr als 90% des belegten Diskspace sparen.

Dann hast Du eingestellt, daß die Logdateien allgemein wöchentlich 
(Zeile "weekly") rotiert werden sollen und die alten Logddateien für 
vier Wochen (Zeile "rotate 4") aufbewahrt werden sollen.

Klar: wenn Dir ein Programm die Logs zumüllt, die Logs nicht komprimiert 
und dann auch noch vier Wochen aufbewahrt werden, wird die ganze Sache 
ziemlich umfangreich.

Du könntest "rotate" auf 0 setzen, dann werden alte Logs sofort 
gelöscht, und das "weekly" durch "daily" ersetzen, dann werden sie 
täglich rotiert. Außerdem ist es sicher keine so schlechte Idee, die 
Komprimierung wieder einzuschalten, indem Du das "#" aus der Zeile 
"#compress" entfernst.

Aber das sind nur die Standardvorgaben. Viel interessanter dürften die 
Dateien unter /etc/logrotate.d/ sein, die für die einzelnen Programme 
gelten. Könntest Du diese Dateien bitte noch zeigen, damit wir da mal 
drüber schauen können? Insbesondere /etc/logrotate.d/rsyslog ist wohl 
besonders spannend, aber die anderen Dateien natürlich auch.

> Sheeva P. schrieb:
>> sind Deine Logs
>> dann aber weg, was besonders ärgerlich ist, wenn man die Fehlerursache
>> herausfinden möchte. Eine bessere Alternative könnte es daher sein, auf
>> einen anderen Host mit einer Festplatte
>
> auf das NAS?

Ja, zum Beispiel. Auf dem Zielsystem muß halt ein Logserver laufen, der 
die Nachrichten entgegennimmt und persistiert. Oder, wie gesagt, Du 
kannst auch einen USB-Stick oder eine Disk an den RasPi stöpseln und 
darauf loggen, wie es Dir lieber ist... ;-)

> aber das macht auch jeden Montag um 2 Uhr ein reboot.

Das kann rsyslogd(8) ab und wird die in dieser Zeit anfallenden 
Nachrichten puffern, bis der Loghost wieder verfügbar ist. Schließlich 
kann es in einem Netzwerk immer mal vorkommen, daß ein Host nicht 
erreichbar ist. Wenn es für das Synology einen Logserver gibt, sollte es 
kein großes Problem sein, darauf zu loggen.

> Mir wird immer wieder gesagt das Linux das nicht braucht, ABER wenn ich
> ins System vom Qnap schaue gibt es dort Meldungen das es lange nicht
> mehr neu gestartet wurde und es empfohlen ist, irgendwie ein
> Widerspruch?

Das ist eine Frage für den Qnap-Support. Ich habe keine Ahnung, was die 
da machen. Normalerweise muß man ein Linux heute nur noch dann rebooten, 
wenn ein Kernelupdate stattgefunden hat. Einige Distributoren und 
Entwickler arbeiten daran, den Kernel live patchen zu können, und das 
soll bei einigen Implementierungen auch schon funktionieren, aber diese 
Implementierungen sind meines Wissens alle kommerziell und ich habe 
keine Erfahrung damit.

Früher mußte man ein Linux auch dann rebooten, wenn der Hostname 
geändert worden ist. Keine Ahnung, ob das noch notwendig ist; bei mir 
findet das Setzen des Hostnamen bei der Installation statt, und nach 
deren Abschluß muß das System ohnehin rebootet werden. ;-)

> Ich weiss aber das garbage collection irgendwie nicht mehr in ist, ich
> kenne das noch von früher, aber richtiges Aufräumen von Speicherlöchern
> klappt wohl nur theoretisch?

Die Defragmentierung machen moderne Linux-Dateisysteme selbständig, wenn 
das a) notwendig ist und b) das System gerade wenig zu tun hat. Aber ich 
kenne die Synology-Systeme nur vom Namen und weiß daher weder, welches 
Dateisystem die verwenden, noch, ob es in regelmäßigen Abständen einen 
Dateisystemcheck beim Booten durchführen will.

Abschließend nochmals: bitte tu' nichts, bevor ich es Dir sage. Das 
werde ich allerdings erst tun, wenn ich Dein Setup verstanden habe und 
sicher bin, daß meine Empfehlungen Dein System nicht beschädigen. Ok?

[Karl K. (karl2go)]

Sheeva P. schrieb:
> ... weswegen die Logdateien bei der
> Rotation nicht komprimiert werden. Durch die Komprimierung kann man da
> aber häufig mehr als 90% des belegten Diskspace sparen.

Wobei ich es beim Raspi sinnvoller finden würde, die alten Logs gleich 
zu löschen. Beim Komprimieren werden bereits geschriebene gelöscht und 
die Komprimierten neu geschrieben, was der Minimierung der 
Speicherzugriffe auf die SD-Karte zuwiderläuft.

Ich finde auch gerade keinen Grund, diese Logs länger als eine Woche 
aufzuheben. Entweder es gibt ein ernstes Problem und ich schau mir das 
zeitnah an, oder es war doch nicht so wichtig.

[17°C and dropping (Gast)]

Sheeva P. schrieb:


Nachtschicht?


> Klar: wenn Dir ein Programm die Logs zumüllt, die Logs nicht komprimiert
> und dann auch noch vier Wochen aufbewahrt werden, wird die ganze Sache
> ziemlich umfangreich.
>
> Du könntest "rotate" auf 0 setzen, dann werden alte Logs sofort
> gelöscht, und das "weekly" durch "daily" ersetzen, dann werden sie
> täglich rotiert. Außerdem ist es sicher keine so schlechte Idee, die
> Komprimierung wieder einzuschalten, indem Du das "#" aus der Zeile
> "#compress" entfernst.
>
> ...


Schon aber wozu Sinn der Aktion war doch die Schreiblast zu verringern, 
wenn man den Müllerzeuger nicht in den Griff bekommt z.B.:

>> /usr/bin/synergyc --name raspbianPI3 --log /dev/null 192.168.178.20

oder "-- log logmichdochsonstwo" nicht fruchtet weil sich synergy anders 
verhält als seine Hilfsdatei beschreibt dann ist es doch geschickter den 
syslog anzuweisen synergy Meldungen an bestimmte stellen zuschreiben 
oder ganz zu ignorieren.

 

/etc/syslog.conf


Alles was von synergy kommt ignorieren:
synergy*.none, synergy*.!*, synergy*.!debug, .....

alles höher gleich debug nach /usr/adm/debug
synergy*.=debug            /usr/adm/debug 

oder wenn z.B. tmp beim Systemstart geleert wird
synergy*.=debug            /tmp/logmich_nur_solang_ich_laufe            

usw.

klogd syslogd alte syntax, rsyslog kennt viel mehr

man man

[Johannes S. (Gast)]

ich habe das mal ausprobiert. Auf dem RPi läuft rsyslogd, die 
syslog.conf gibt es nicht aber rsyslog.conf. Da habe ich diese Zeilen 
angehängt:

#
## Exceptions for synergy, 20180826
#
synergy*.none, synergy*.!*, synergy*.!debug, synergy*.!warning, synergy*.!info

trotzdem läuft das logging fröhlich weiter:

[ Service ] [2018-08-26T12:06:10] error: websocket connect failed
[ Service ] [2018-08-26T12:06:10] debug: retrying websocket connection in 21s
[ Router  ] [2018-08-26T12:06:10] debug: binding to 0.0.0.0:24802
[ Router  ] [2018-08-26T12:06:10] debug: Initialized
[ Service ] [2018-08-26T12:06:10] debug: setting core uid from config: 1000
[ Service ] [2018-08-26T12:06:10] info: Session monitor started
[ Service ] [2018-08-26T12:06:10] debug: creating rpc endpoints
[ Service ] [2018-08-26T12:06:10] debug: rpc endpoints created
[ Service ] [2018-08-26T12:06:17] info: Active X session changed from "--" to "c1"
[ Service ] [2018-08-26T12:06:17] info: Active X session user changed from "--" to "1000"
[ Service ] [2018-08-26T12:06:17] info: Active X session display changed from "--" to ":0"
[ Service ] [2018-08-26T12:06:51] debug: retrying websocket connection now
[ Service ] [2018-08-26T12:06:51] debug: connecting websocket: pubsub1.cloud.symless.com:443
[ Service ] [2018-08-26T12:06:52] debug: cloud client connected
[ Service ] [2018-08-26T12:06:52] debug: websocket connected
[ Service ] [2018-08-26T12:06:52] debug: comparing profiles, id=-1 this=v-1 other=v397
[ Service ] [2018-08-26T12:06:52] debug: profile id changed, -1->71926
[ Service ] [2018-08-26T12:06:52] debug: profile name changed, ->default
[ Service ] [2018-08-26T12:06:52] debug: profile server changed, -1->183107
[ Service ] [2018-08-26T12:06:52] debug: profile screen set changed, added=5 removed=0
[ Service ] [2018-08-26T12:06:52] debug: Waiting for screen 183107 to become reachable
[ Service ] [2018-08-26T12:06:52] debug: Waiting for screen 183272 to become reachable
[ Router  ] [2018-08-26T12:06:52] debug: Starting...
[ Router  ] [2018-08-26T12:06:52] debug: ID = 183272, Name = 'JojosRPi3-1'

bezieht sich der Filter 'synergy*.' auf den logfile Namen oder die 
Messages wie hier [ Service ], [ Router ] usw. ?

pi@JojosRPi3-1:/var/log/synergy $ ls -ali
insgesamt 44
81615 drwxrwxrwx  2 root root  4096 Aug 26 12:14 .
  216 drwxr-xr-x 14 root root  4096 Aug 26 12:13 ..
   36 -rw-r--r--  1 root root 12971 Aug 26 12:14 synergy-combined.log
   48 -rw-r--r--  1 pi   root  2003 Aug 26 12:14 synergy-core.log
   70 -rw-r--r--  1 root root  6250 Aug 26 12:14 synergy-router.log
   52 -rw-r--r--  1 root root  4158 Aug 26 12:14 synergy-service.log

[Johannes S. (Gast)]

Egon D. schrieb:
> Irgendwas der Art
>
>   ln -s /var/log/synergyzeugs.log /dev/null
>
> ist nicht denkbar?

wenn man Ziel und Referenz in der richtigen Reihenfolge angibt dann ja:

sudo rm /var/log/synergy/*
sudo ln -s /dev/null /var/log/synergy-core.log
sudo ln -s /dev/null /var/log/synergy-router.log
sudo ln -s /dev/null /var/log/synergy-service.log
sudo ln -s /dev/null /var/log/synergy-combined.log

i@JojosRPi3-1:/var/log/synergy $ ls -ali
insgesamt 8
81615 drwxrwxrwx  2 root root 4096 Aug 26 12:28 .
  216 drwxr-xr-x 14 root root 4096 Aug 26 12:29 ..
 1365 lrwxrwxrwx  1 root root    9 Aug 26 12:28 synergy-combined.log -> /dev/null
   48 lrwxrwxrwx  1 root root    9 Aug 26 12:28 synergy-core.log -> /dev/null
 1335 lrwxrwxrwx  1 root root    9 Aug 26 12:28 synergy-router.log -> /dev/null
 1351 lrwxrwxrwx  1 root root    9 Aug 26 12:28 synergy-service.log -> /dev/null

Das sind die Logdateinamen für syngery V2. Es ist natürlich ein 
Würgaround weil das logging damit komplett in die Tonne geht. Ist für 
mich aber erstmal ok bis Symless den debuglevel einstellbar macht.

[Joachim B. (jar)]

Sheeva P. schrieb:
> Also, kurz gesagt: Du hast ein Synology NAS, einen RasPi, sowie noch
> einen Windows-Rechner, der vermutlich Deine primäre Arbeitsmaschine ist.

Qnap, Rest JA

Sheeva P. schrieb:
> Ah, also beim Login über den Autostart von LXDE. Das funktioniert
> natürlich nur dann, wenn Du Dich in den LXDE einloggst.

das genügt, übers Netz nutze ich x11vnc

Sheeva P. schrieb:
> daß sowohl der RasPi als auch Dein Windows-Rechner
> jeweils einen eigenen Monitor haben

ja genauer gesagt 3 Monitore, der andere Monitor wird vom 2t PC mittels 
maxivista (als Client) angesteuert, oder läuft autark um mehr CPU zu 
haben, aber hat auch keine Tastatur und Maus.

Sheeva P. schrieb:
> Da das Skript vermutlich Deinem Benutzer gehört und auch nicht für Group
> und Others les-, beschreib- oder ausführbar sein muß, würde "chmod 700
> ..." ohne sudo hier völlig ausreichen.

hatte ich so gelesen oder rausgefunden, 777 funktionierte halt, mir war 
schon klar das völlige Freigabe zuviel ist aber wie ich sagte so der 
Profi bin ich nicht und wenn eine Lösung für mich funktioniert.......

Sheeva P. schrieb:
> Nun, Du sagst, daß der synergyc nur dann wie wild loggt, wenn der
> "Server" nicht verfügbar ist. Ist mit "Server" Dein Synology NAS
> gemeint?

nein, Server (im Sinne von Synergy) ist für Maus und Tastaur Sharing der 
PC dessen Maus und Tastatur genutzt wird, Client (im Sinne von Synergy) 
ist der PC der keine Maus und Tastatur angeschlossen hat.

Sheeva P. schrieb:
> wenngleich noch einige meiner
> Fragen offen sind und sich weitere stellen

ich glaube hier bist du falsch abgebogen

Sheeva P. schrieb:
> Soweit ich weiß, haben die Synologies aber
> keine GUI, sondern nur ein Webfrontend

1. Qnap, 2. hat nichts mit Synergy zu tun, mir ging es bei Nennung vom 
NAS ums logging um die Schreibbelastung der miroSD zu reduzieren.

ich glaube hier bist du falsch abgebogen

Sheeva P. schrieb:
> wenn Du nie an den Logs Deines synologyc interessiert bist.

es geht nicht um NAS LOGs

Sheeva P. schrieb:
> könnten wir die Veranstaltung ein wenig umbauen, so daß das
> Skript nicht einfach nur stumpf den synologyc startet, sondern etwa so
> eine Logik implementiert
Sheeva P. schrieb:
> sleep 60
Sheeva P. schrieb:
> Damit würde das Programm alle sechzig Sekunden nachschauen, ob der
> Server verfügbar ist

hatte ich versucht, aber das setzt den PI ja ausser Betrieb, der schläft 
offensichtlich wirklich, bzw. reagiert dann äusserst träge.
Ich dachte auch das sleep 60 dem OS mehr CPU Zeit lässt (so wie ich das 
kenne), aber dem war nicht so, oder der Synergy hat grundsätzliche 
Probleme das er tillt und deswegen alle Sekunde "gekillt" neu gestartet 
wird. vgl. dem lten webserver Dienst auf dem gezeigten Raidsonic NAS 
2001b/4220b, da war ja ein ähnliches Problem: Der Webserver schmierte 
ab, das NAS war nicht mehr erreichbar, also wurde nach Ausfall vom 
Webserver der Dienst "gekillt" und neu gestartet, eigentlich sind das ja 
workarounds die als Notnagel gemacht werden von Usern, hier bei Synergy 
war es die "Empfehlung" aus einer Webseite unter Autostart.

Sheeva P. schrieb:
> Was mir auf den ersten Blick auffällt: die Komprimierung ist
> ausgeschaltet

verstehe ich aber nicht weil ich von den Syslogs auch .gz fand.

Sheeva P. schrieb:
> unter /etc/logrotate.d/ sein, die für die einzelnen Programme
> gelten. Könntest Du diese Dateien bitte noch zeigen, damit wir da mal
> drüber schauen können? Insbesondere /etc/logrotate.d/rsyslog ist wohl
> besonders spannend,

das erklärt es natürlich:
syslog:

/var/log/syslog
{
  rotate 7
  daily
  missingok
  notifempty
  delaycompress
  compress
  postrotate
    invoke-rc.d rsyslog rotate > /dev/null
  endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
  rotate 4
  weekly
  missingok
  notifempty
  compress
  delaycompress
  sharedscripts
  postrotate
    invoke-rc.d rsyslog rotate > /dev/null
  endscript
}

der Rest unauffällig mit compress ON das erklärt weitere .gz Dateien, 
könnte man abschalten.

Sheeva P. schrieb:
> Wenn es für das Synology einen Logserver gibt, sollte es
> kein großes Problem sein, darauf zu loggen.

??? Qnap, dürfte aber auch einen LOG Server haben, wäre halt eine Option 
die die Schreibbelastung von der SD fernhält, aber mit geeignetem Umbau, 
keine unnötigen LOGs, LOGs in RAMDISK und nur gelegentlich sichern auf 
microSD Card dürfte eigentlich genügen, bei einer GB großen microSD und 
LOG Dateien bis 1 MB, wer bitte will mehr lesen, wenn es soweit kommt 
hat man andere Probleme!

Die Idee mit dem NAS kam ja nur weil die Dateien zu groß anwachsen und 
zu oft geschrieben wurden, als letzter Ausweg.

Sheeva P. schrieb:
> Früher mußte man ein Linux auch dann rebooten, wenn der Hostname
> geändert worden ist. Keine Ahnung, ob das noch notwendig ist

heute eher nicht, ich habe den Hostnamen auch geändert und Samba 
restartet.

Sheeva P. schrieb:
> Das ist eine Frage für den Qnap-Support.

Meine Lust irgendwelche Supports zu fragen hat sich im letzten Jahr 
deutlich minimiert, entweder kam ich über Telefonhotline angeblich 
deutsch sprechenden Supporter die weder die Frage in deutsch noch in 
englich verstanden, letztens sogar nicht mal die Gleichheit von 
Schalterkontakt und Relaiskontakt verstanden, es ging um 
Potenzialfreiheit.

Karl K. schrieb:
> Ich finde auch gerade keinen Grund, diese Logs länger als eine Woche
> aufzuheben. Entweder es gibt ein ernstes Problem und ich schau mir das
> zeitnah an, oder es war doch nicht so wichtig.

dito

17°C and dropping schrieb:
> Schon aber wozu Sinn der Aktion war doch die Schreiblast zu verringern,
> wenn man den Müllerzeuger nicht in den Griff bekommt z.B.:
>
>>> /usr/bin/synergyc --name raspbianPI3 --log /dev/null 192.168.178.20
>
> oder "-- log logmichdochsonstwo" nicht fruchtet weil sich synergy anders
> verhält als seine Hilfsdatei beschreibt dann ist es doch geschickter den
> syslog anzuweisen synergy Meldungen an bestimmte stellen zuschreiben
> oder ganz zu ignorieren.

das war eigentlich mein Ziel

was soll ich mit der LOG Meldung das der Synergy Server (mit Maus und 
Tastatur) offline ist weil ausgeschaltet?
was soll ich mit der LOG Meldung das die MAUS sich nun im PI Fenster 
befindet? das weiss ich doch selber.

[Johannes S. (Gast)]

Joachim B. schrieb:
> was soll ich mit der LOG Meldung das der Synergy Server (mit Maus und
> Tastatur) offline ist weil ausgeschaltet?
> was soll ich mit der LOG Meldung das die MAUS sich nun im PI Fenster
> befindet? das weiss ich doch selber.

dann müsste doch die Umleitung in den Datenhimmel auch reichen, den Tipp 
von Egon habe ich ja gerade getestet und das klappt. Die Dateinamen für 
die V1 müssen nur entsprechend angepasst werden.

[17°C and dropping (Gast)]

Johannes S. schrieb:
> ich habe das mal ausprobiert. Auf dem RPi läuft rsyslogd, die
> syslog.conf gibt es nicht aber rsyslog.conf. Da habe ich diese Zeilen
> angehängt:
>
>

> #
> ## Exceptions for synergy, 20180826
> #
> synergy*.none, synergy*.!*, synergy*.!debug, synergy*.!warning, 
> synergy*.!info
>

>
> trotzdem läuft das logging fröhlich weiter:

Der vollständigkeit halber:

syslog nicht rsyslog!

----
Discard

If the discard action is carried out, the received message is 
immediately discarded. Discard can be highly effective if you want to 
filter out some annoying messages that otherwise would fill your log 
files. To do that, place the discard actions early in your log files. 
This often plays well with property-based filters, giving you great 
freedom in specifying what you do not want.

Discard is just the single tilde character with no further parameters.

Example:
    *.* ~ # discards everything.


----


War jetzt nicht weiter verwunderlich das es so nicht funktioniert.

synergy*.none,
synergy*.!*,
synergy*.!debug

die drei Ausdrücke sind identisch, debug ist der niedrigste level
aus man syslog

You may use it intuitively as an exception specifier.  The  above  men-
       tioned interpretation is simply inverted.  Doing that you may use

            mail.none
       or
            mail.!*
       or
            mail.!debug

       to  skip  every message that comes with a mail facility.  There is much
       room to play with it. :-)

> bezieht sich der Filter 'synergy*.' auf den logfile Namen oder die
> Messages wie hier [ Service ], [ Router ] usw. ?


"logging facilty"


-r-syslog unterstützt das wohl bis zu einer gewissen Version.


wenn dann fiele das auch unter old-stylerules

https://www.rsyslog.com/doc/rsyslog%255Fconf%255Ffilter.html

rsyslog.com stackexchange.com
Das wären die richtigen Anlaufstellen.

heute mit rsyslog sieht das wohl so aus:


if $programname == 'foobar' and $syslogseverity-text == 'error' then 
/var/log/foobar.log



---
EOT

[Egon D. (Gast)]

Johannes S. schrieb:

> Egon D. schrieb:
>> Irgendwas der Art
>>
>>   ln -s /var/log/synergyzeugs.log /dev/null
>>
>> ist nicht denkbar?
>
> wenn man Ziel und Referenz in der richtigen Reihenfolge

Hmpf. Das darf doch nicht wahr sein...
Die richtige Reihenfolge kann ich mir schon seit ungefähr
20 Jahren nicht merken.

Danke für die Richtigstellung.


> angibt dann ja:

Freut mich, wenn es geholfen hat.


> sudo rm /var/log/synergy/*
> sudo ln -s /dev/null /var/log/synergy-core.log
> [...]

[Kommandozeile vor dem Frühstück für Alle! (Gast)]

>>>   ln -s /var/log/synergyzeugs.log /dev/null
>>>
>>> ist nicht denkbar?
>>
>> wenn man Ziel und Referenz in der richtigen Reihenfolge
>
> Hmpf. Das darf doch nicht wahr sein...
> Die richtige Reihenfolge kann ich mir schon seit ungefähr
> 20 Jahren nicht merken.

Eselsbrücke: gleich wie cp

$ cp von/der/original/Quelle zur/kopie/Ziel
$ ln -s von/war/bereits/da zu/neu/erstellt #klar wird der Symb.Link neu erstellt!

Latürnich ist danach die Darstellung mit dem Pfeil in die umgekehrte 
Richtung:
symlink->Original
Man will ja das Original mittels dem neu zu erstellenden Symlink, also 
einem zusätzlichen Namen, erreichen.

[Joachim B. (jar)]

Johannes S. schrieb:
> wenn man Ziel und Referenz in der richtigen Reihenfolge angibt dann ja:
>
>

> sudo rm /var/log/synergy/*
> sudo ln -s /dev/null /var/log/synergy-core.log
> sudo ln -s /dev/null /var/log/synergy-router.log
> sudo ln -s /dev/null /var/log/synergy-service.log
> sudo ln -s /dev/null /var/log/synergy-combined.log
>

>
> Das sind die Logdateinamen für syngery V2. Es ist natürlich ein
> Würgaround weil das logging damit komplett in die Tonne geht. Ist für
> mich aber erstmal ok bis Symless den debuglevel einstellbar macht.

eine Idee was bei 1.4.16 benötigt wird?

[Johannes S. (Gast)]

welche Dateien liegen bei dir in /var/log oder werden die da auch schon 
nach /var/log/synergy geschrieben?

[Sheeva P. (sheevaplug)]

Joachim B. schrieb:
> Sheeva P. schrieb:
>> Ah, also beim Login über den Autostart von LXDE. Das funktioniert
>> natürlich nur dann, wenn Du Dich in den LXDE einloggst.
>
> das genügt, übers Netz nutze ich x11vnc
>
> Sheeva P. schrieb:
>> daß sowohl der RasPi als auch Dein Windows-Rechner
>> jeweils einen eigenen Monitor haben
>
> ja genauer gesagt 3 Monitore, der andere Monitor wird vom 2t PC mittels
> maxivista (als Client) angesteuert, oder läuft autark um mehr CPU zu
> haben, aber hat auch keine Tastatur und Maus.

Jetzt hast Du mich komplett abgehängt... Drei Rechner, jeder treibt 
einen eigenen Monitor, aber Tastatur und Maus gibt es nur an einem der 
Rechner, die sollen aber alle drei bespielen?

> Sheeva P. schrieb:
>> Da das Skript vermutlich Deinem Benutzer gehört und auch nicht für Group
>> und Others les-, beschreib- oder ausführbar sein muß, würde "chmod 700
>> ..." ohne sudo hier völlig ausreichen.
>
> hatte ich so gelesen oder rausgefunden, 777 funktionierte halt, mir war
> schon klar das völlige Freigabe zuviel ist aber wie ich sagte so der
> Profi bin ich nicht und wenn eine Lösung für mich funktioniert.......

Das "works for me" ist leider meistens der falsche Ansatz, das geht oft 
beim nächsten Update oder bei anderen Änderungen am System kaputt.

> Sheeva P. schrieb:
>> Nun, Du sagst, daß der synergyc nur dann wie wild loggt, wenn der
>> "Server" nicht verfügbar ist. Ist mit "Server" Dein Synology NAS
>> gemeint?
>
> nein, Server (im Sinne von Synergy) ist für Maus und Tastaur Sharing der
> PC dessen Maus und Tastatur genutzt wird, Client (im Sinne von Synergy)
> ist der PC der keine Maus und Tastatur angeschlossen hat.

Ah, ok.

> Sheeva P. schrieb:
>> könnten wir die Veranstaltung ein wenig umbauen, so daß das
>> Skript nicht einfach nur stumpf den synologyc startet, sondern etwa so
>> eine Logik implementiert
> Sheeva P. schrieb:
>> sleep 60
> Sheeva P. schrieb:
>> Damit würde das Programm alle sechzig Sekunden nachschauen, ob der
>> Server verfügbar ist
>
> hatte ich versucht, aber das setzt den PI ja ausser Betrieb, der schläft
> offensichtlich wirklich, bzw. reagiert dann äusserst träge.

Sehr merkwürdig. GNU sleep(1) nutzt die GNU-Libraryfunktion 
xnanosleep(), welche wiederum den Linux-Systembefehl nanosleep() 
aufruft. Dadurch wird der Prozeß tatsächlich schlafen geschickt und 
verbraucht dann keine CPU-Leistung mehr, bis er vom Kernel wieder 
aufgeweckt wird. Das bestätigen auch meine Versuche mit einem alten 
Raspbian Jessie auf einem RasPi1.

> Ich dachte auch das sleep 60 dem OS mehr CPU Zeit lässt (so wie ich das
> kenne), aber dem war nicht so, oder der Synergy hat grundsätzliche
> Probleme das er tillt und deswegen alle Sekunde "gekillt" neu gestartet
> wird.

Könntest Du das bitte etwas genauer beschreiben?

> Sheeva P. schrieb:
>> unter /etc/logrotate.d/ sein, die für die einzelnen Programme
>> gelten. Könntest Du diese Dateien bitte noch zeigen, damit wir da mal
>> drüber schauen können? Insbesondere /etc/logrotate.d/rsyslog ist wohl
>> besonders spannend,
>
> das erklärt es natürlich:
> syslog:
>

> /var/log/syslog
> {
>   rotate 7
>   daily
>   [...]
> }
> 
> /var/log/mail.info
> /var/log/mail.warn
> /var/log/mail.err
> /var/log/mail.log
> /var/log/daemon.log
> /var/log/kern.log
> /var/log/auth.log
> /var/log/user.log
> /var/log/lpr.log
> /var/log/cron.log
> /var/log/debug
> /var/log/messages
> {
>   rotate 4
>   weekly
>   [...]
> }
>

Ok, setz' beide "rotate"-Einträge auf "0".

Ich sehe aber immer noch keine Konfiguration für etwas, das nach 
"synergy" oä. aussieht. Loggt das Ding überhaupt via Syslog oder 
Rsyslog? Die von Dir geposteten Logmeldungen sehen irgendwie nicht 
danach aus.

Wenn ich die Dokumentation von dem synergyc richtig lese, loggt das Ding 
entweder auf ein Terminalfenster, wenn er mit "--no-daemon" bzw. "-f" 
gestartet wird, und via syslog nur dann wenn er mit "--daemon" gestartet 
worden ist. Hast Du diese Optionen einmal ausprobiert?

Ich persönlich würde mich ja mal von einer remote-Büchse auf der CLI von 
diesem RasPi einloggen und sowas wie strace(1), ltrace(1) oder 
latrace(1) auspacken. Was brauche ich, um ein Setup wie Deins grob 
nachzustellen? Allerdings ist das eher etwas für Profis... ;-)

> was soll ich mit der LOG Meldung das der Synergy Server (mit Maus und
> Tastatur) offline ist weil ausgeschaltet?
> was soll ich mit der LOG Meldung das die MAUS sich nun im PI Fenster
> befindet? das weiss ich doch selber.

Wenn die Software sich nicht so verhält, wie ihre Dokumentation es sagt, 
dann ist das erstens ein Bug, den Du den Debian-Maintainern des Pakets 
mitteilen solltest. Und für mich wäre so etwas zweitens ein Anlaß, mich 
nach einer Alternative umzusehen. ;-)

[Joachim B. (jar)]

Sheeva P. schrieb:
> Jetzt hast Du mich komplett abgehängt... Drei Rechner, jeder treibt
> einen eigenen Monitor, aber Tastatur und Maus gibt es nur an einem der
> Rechner, die sollen aber alle drei bespielen?

ganz genau, ich habe zwar Platz für 3 Monitore an 3 Rechner zumal der PI 
ja nicht wirklich Platz braucht, aber Platz für 3 Tastaturen habe ich 
nicht, wäre auch Unfug.

>> Sheeva P. schrieb:
>>> und Others les-, beschreib- oder ausführbar sein muß, würde "chmod 700
>>> ..." ohne sudo hier völlig ausreichen.
>
> Das "works for me" ist leider meistens der falsche Ansatz, das geht oft
> beim nächsten Update oder bei anderen Änderungen am System kaputt.

Das ist aber dann eine andere Baustelle, bei mir tun sich gerade zu 
viele auf um überall tätig zu werden, persönlich würde ich dir das auch 
erklären.

>> Ich dachte auch das sleep 60 dem OS mehr CPU Zeit lässt (so wie ich das
>> kenne), aber dem war nicht so, oder der Synergy hat grundsätzliche
>> Probleme das er tillt und deswegen alle Sekunde "gekillt" neu gestartet
>> wird.
>
> Könntest Du das bitte etwas genauer beschreiben?

kann ich nicht, das Installationsscript hatte ich so übernommen und 
funktioniert ja bestens MIT SLEEP1 und Kill

>> /var/log/mail.info
>> /var/log/mail.warn
>> /var/log/mail.err
>> /var/log/mail.log
>> /var/log/daemon.log
>> /var/log/kern.log
>> /var/log/auth.log
>> /var/log/user.log
>> /var/log/lpr.log
>> /var/log/cron.log
>> /var/log/debug
>> /var/log/messages
>> {
>>   rotate 4
>>   weekly
>>   [...]
>> }
>
> Ok, setz' beide "rotate"-Einträge auf "0".

OK mache ich gerne

> Ich sehe aber immer noch keine Konfiguration für etwas, das nach
> "synergy" oä. aussieht. Loggt das Ding überhaupt via Syslog oder
> Rsyslog? Die von Dir geposteten Logmeldungen sehen irgendwie nicht
> danach aus.

Synergy loggt genauer gesagt in
"Synergy" /var/log/debug
"Synergy" /var/log/daemon.log
"Synergy" /var/log/syslog
"action 17" /var/log/messages

momentan lösche ich alle diese LOGs weil es nervt und die SD füllt

wenn hier alles wunschgemäß klappt ist Holzhammer alles löschen evtl. 
nicht mehr nötig

>> was soll ich mit der LOG Meldung das der Synergy Server (mit Maus und
>> Tastatur) offline ist weil ausgeschaltet?
>> was soll ich mit der LOG Meldung das die MAUS sich nun im PI Fenster
>> befindet? das weiss ich doch selber.
>
> Wenn die Software sich nicht so verhält, wie ihre Dokumentation es sagt,
> dann ist das erstens ein Bug, den Du den Debian-Maintainern des Pakets
> mitteilen solltest. Und für mich wäre so etwas zweitens ein Anlaß, mich
> nach einer Alternative umzusehen. ;-)

Bug ist ja bekannt und auch bei V2 trotz Meldung nie behoben worden
Das kannte ich ja schon bei der Kaufversion vom raidsonic NAS 2001B und 
4220B

Was soll man Meldungen an Autoren schicken, die letzte Autorenmeldung 
hatte ich bei fastLED am Arduino mighty mini 1284p:
Antwort, seine Ardus laufen, mighty mini kennt er nicht, er sieht keinen 
Grund was zu ändern, ich könnte ihm ja einen schicken.

Ich habe dann die fastLED LIB per #define selber gepatched, war ja nur 
ein #define auf _ATmega1284p_, durch den vergößerten Speicher 128k 
wurde die 64K Grenze überschritten, der Zugriff um ein Byte erweitert 
verlängerte die Zugriffszeiten um 10% so das das  Timing nicht mehr 
eingehalten wurde, ich habe hinter dem #define einfach F_CPU auf 90% 
gesetzt um diese 10% Verlängerung zu kompensieren.
schmutzig aber funktioniert.
Beitrag "Arduino FastLED LIB vs. WS28xx LIB"

// Macro to convert from nano-seconds to clocks and clocks to nano-seconds
// __AVR_ATmega1284P__
// #define NS(_NS) (_NS / (1000 / (F_CPU / 1000000L)))
#if F_CPU < 96000000
    #if defined(__AVR_ATmega1284P__)
        #define NS(_NS) ( (_NS * ( ((long)(F_CPU*9L/10L)) / 1000000L))) / 1000
        #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (((long)(F_CPU*9L/10L)) / 1000000L)
    #else
        #define NS(_NS) ( (_NS * (F_CPU / 1000000L))) / 1000
        #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (F_CPU / 1000000L)
    #endif
#else
    #define NS(_NS) ( (_NS * (F_CPU / 2000000L))) / 1000
    #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (F_CPU / 2000000L)
#endif

[wtf? (Gast)]

>
> Synergy loggt genauer gesagt in
> "Synergy" /var/log/debug
> "Synergy" /var/log/daemon.log
> "Synergy" /var/log/syslog
> "action 17" /var/log/messages
>
> momentan lösche ich alle diese LOGs weil es nervt und die SD füllt
>

Weshalb startest du dann den logger überhaupt?
Irgendwie glaube ich nicht das du die noch vor dem löschen mal 
durchgehst.

Halte den doch einfch mal an um zu sehen ob weiter irgendwo Meldungen 
auftauchen und wenns blos ein krudes killall rsyslogd oder kill -KILL 
rsyslogd-pid ist. systemd: systemctl stop syslog.socket rsyslog.service


Wie man sich mit sowas wochenlang beschäftigen kann!?

/etc/rsyslog.conf
if $syslogseverity-text == 'debug' then /dev/null

würde unter einem aktuellen RRRRRRRrsyslog schon mal 90% meldungen 
schlucken welche Johannes S. weiter oben gezeigt hat, wenns 
interessantes anderer Programme im level debug gibt muss man eben weiter 
sortieren, irgendwie wird sich das synergy schon identifizieren lassen. 
Und wenn die syntax eben nicht stimmt dann schaut in die Doku, rsyslog 
ist garantiert auf Zack und aktiv gepflegt.

[Joachim B. (jar)]

wtf? schrieb:
> Weshalb startest du dann den logger überhaupt?

what the fail?

ICH starte den logger nicht, manno warum kommen immer solche Kommentare?
-> Dieter Nuhr

[Johannes S. (Gast)]

rsyslogd wird ja per default installiert und gestartet, den komplett 
abzuschalten ist natürlich die Holzhammermethode. Aber zum Testen wäre 
das interessant. Bei der synergy v2 (die nach /var/log/synergy loggt) 
konnte ich die Meldungen mit dem vorgeschlagenen Filtern nicht 
entfernen, ich vermute die v2 hat einen eigenen logger eingebaut. Das 
werde ich heute abend testen.

Für die v1 hatte ich gefragt ob die auch ein /var/log/synergy 
Verzeichnis anlegt. Was gibt 'ls /var/log/synergy' aus?

[Joachim B. (jar)]

Johannes S. schrieb:
> Für die v1 hatte ich gefragt ob die auch ein /var/log/synergy
> Verzeichnis anlegt.

wird nicht angelegt, alle Synergy Logs landen in

> Synergy loggt genauer gesagt in
> "Synergy" /var/log/debug
> "Synergy" /var/log/daemon.log
> "Synergy" /var/log/syslog
> "action 17" /var/log/messages

NICHT ABSCHALTBAR!

ich schreie ja nur ungern, aber so wird das langsam zur farce
ich habe alles geschrieben und immer wieder kommen Nachfragen weil nicht 
gelesen wird?

[what the FUCK (Gast)]

Joachim B. schrieb:
> wtf? schrieb:
>> Weshalb startest du dann den logger überhaupt?
>
> what the fail?
>


What the fuck.

> ICH starte den logger nicht, manno warum kommen immer solche Kommentare?
> -> Dieter Nuhr

Nuhr ist ein Dummschwätzer. Du schriebst doch doch alles zu löschen was 
der logged dann brauch er auch nicht laufen. .

Du schaltest deine Rechner ein und hoffst das sie tun was du dir 
wünschst?
Wozu gibts denn runlevel und heute system and service manager?

[what the FUCK (Gast)]

Joachim B. schrieb:

> ich habe alles geschrieben und immer wieder kommen Nachfragen weil nicht
> gelesen wird?




>>>Sheeva P. schrieb:
>>> Schreibt die Software ihre eigenen Logdateien, oder loggt sie über
>>> rsyslogd bzw. journald?

>>synergy logt in debug, daemon, syslog

Aha,


Anwendung:Meldung -> journald:weiterleitung -> rsyslogd:Eintrag_in_Datei

Auf Nuhr-Niveau:

rsyslogd abschalten, gucken
journald abschalten, gucken

Du wirst noch Spaß an Linux haben ;)

[Sheeva P. (sheevaplug)]

what the FUCK schrieb:
> Anwendung:Meldung -> journald:weiterleitung

Lies doch einfach den Thread, bevor Du den Lauten machst. Raspbian 
Jessie. Kein journald. Nirgends.

[what the FUCK (Gast)]

Sheeva P. schrieb:
> what the FUCK schrieb:
>> Anwendung:Meldung -> journald:weiterleitung
>
> Lies doch einfach den Thread, bevor Du den Lauten machst. Raspbian
> Jessie. Kein journald. Nirgends.

Immer noch nicht kapiert?!

Dann halt bei dir nicht,  ABER eine -systemlogger-


Wenn du alle logs löschst dann brauchst du sie erst garnicht schreiben 
lassen.

2sekunden Suchmaschine:

https://raspberrypi.stackexchange.com/questions/62533/how-can-i-reduce-the-writing-to-log-files

 *.*     ~

nach /etc/rsyslog.conf

ist besser als debug, daemon.log, syslog, messages zu löschen.




Hast du den syslogger nun einmal versuchweise angehalten oder nicht.

[Sheeva P. (sheevaplug)]

what the FUCK schrieb:
> Sheeva P. schrieb:
>> what the FUCK schrieb:
>>> Anwendung:Meldung -> journald:weiterleitung
>>
>> Lies doch einfach den Thread, bevor Du den Lauten machst. Raspbian
>> Jessie. Kein journald. Nirgends.
>
> Immer noch nicht kapiert?!
> [...]
> Hast du den syslogger nun einmal versuchweise angehalten oder nicht.

Mit dem Lesen hast Du es wirklich nicht so, oder? Ich bin nicht Joachim, 
um meine Systeme geht es hier nicht.

[wtf? (Gast)]

Sheeva P. schrieb:

> Mit dem Lesen hast Du es wirklich nicht so, oder? Ich bin nicht Joachim,
> um meine Systeme geht es hier nicht.

Galt nat. nicht dir und wurde hastig unter Annahme eines anderen Autor 
getippt.


----

@Wand

>>>trotzdem läuft das logging fröhlich weiter:

>>>[ Service ] [2018-08-26T12:06:10] error: websocket connect failed
>>>[ Service ] [2018-08-26T12:06:10] debug: retrying websocket conn....
>>>[ Router  ] [2018-08-26T12:06:10] debug: binding to 0.0.0.0:24802
>>>[ Router  ] [2018-08-26T12:06:10] debug: Initialized
>>>[ Service ] [2018-08-26T12:06:10] debug: setting core uid ...
>>>[ Service ] [2018-08-26T12:06:10] info: Session monitor started
>>>[ Service ] [2018-08-26T12:06:10] debug: creating rpc endpoints
>>>[ Service ] [2018-08-26T12:06:10] debug: rpc end

wenn 90% aus den uninteressanten debugmessages besteht,

WO kann man eingreifen?

systemd:

system.conf, otherwise user.conf

options are configured in the "[Manager]" section:
LogLevel=, LogTarget=, LogColor=, ....


und FALLS LogTarget auf journal oder journal-or-kmsg
lenkt weil bpsw. die Kernelmeldungen darüber laufen sollen.
Dann kann immer noch aus journald auf den konvent. syslogger 
weitergeleitet werden.

WENN DAS NICHT SO GEMACHT IST DANN EBEN NICHT

aber auch in journald.conf gäbe es dann wieder
LogLevel=, LogTarget= .....
und eben ggf. ein ForwardToSyslog=


---

Jdf. kann man schon hier LogLevel= bspw. auf info setzen bevor das den 
syslogger z.b. rsyslog erreicht

Anwendung:Meldung ->  systemd:weiterleitung -> evtl. 
journald:weiterleitung -> syslogger:Eintrag_in_Datei
so hätte das lauten sollen, an jedem der wenigsten zwei vorhandenen 
übergabepunkte sollte man jdf. eingreifen können.


Das sollte doch einfach sein, wenns nicht so grobschlächtig ausfallen 
soll muss man eben mal rsyslogs doku lesen.


---

jdf. ist das im Rahmen des möglichen;
raspbian-jessie-lite-default-package-list-dpkg-query

...
libsystemd0:armhf   215-17+deb8u3   armhf   systemd utility library
systemd   215-17+deb8u3   armhf   system and service manager
systemd-sysv   215-17+deb8u3   armhf   system and service manager – SysV 
links
rsyslog (*)   8.4.2-1+deb8u2   armhf   reliable system and kernel 
logging daemon



----


@jojos


orig. syslogd kann nicht wirklich filtern.
die Logfacility zu der das prg. müsste man testen,
vermutlich LOG_DAEMON ,system daemons without separate facility value


---


@all

Keine weiteren Einlassungen zu befürchten.

[Johannes S. (Gast)]

Danke an Sheeva und WTF und die anderen für die Hilfe.
Bitte locker bleiben, der lange Thread ist einfach etwas unübersichtlich 
geworden, natürlich auch weil ich mit meiner synergy 2.x dazugekommen 
bin.
Also Joachim: Raspbian Jessie, synergy 1.x,
ich: Raspbian Stretch, synergy 2.x

Zum logger: auf Stretch läuft rsyslog als service, bei Jessie müsste das 
auch schon so sein.

Und das synergy 2 loggt wie blöde. Es werden log Dateien in 
/var/log/synergy angelegt und es wird über rsyslog ins syslog 
geschrieben. Wenn ich den rsyslog beende ist Ruhe im syslog, aber die 
logs in /var/log/synergy werden weiter geschrieben.
Die Dateien in /var/log/synergy hatte ich ja durch den symbolischen Link 
ins Nirwana geleitet, aber von gestern auf heute sah es so aus:

pi@JojosRPi3-1:/var/log/synergy $ ls -ali
insgesamt 8
81615 drwxrwxrwx  2 root root 4096 Aug 30 22:33 .
  216 drwxr-xr-x 14 root root 4096 Aug 31 06:25 ..
   59 lrwxrwxrwx  1 pi   pi      9 Aug 30 22:33 synergy-combined.log -> /dev/null
   48 lrwxrwxrwx  1 root root    9 Aug 26 12:28 synergy-core.log -> /dev/null
   38 lrwxrwxrwx  1 pi   pi      9 Aug 30 22:33 synergy-router.log -> /dev/null
 1351 lrwxrwxrwx  1 root root    9 Aug 26 12:28 synergy-service.log -> /dev/null
pi@JojosRPi3-1:/var/log/synergy $ ls -ali
insgesamt 3344
81615 drwxrwxrwx  2 root root    4096 Aug 31 14:47 .
  216 drwxr-xr-x 14 root root    4096 Aug 31 06:25 ..
  147 -rw-r--r--  1 root root  683971 Aug 31 15:08 synergy-combined.log
   59 -rw-r--r--  1 root root 1048505 Aug 31 14:47 synergy-combined.log.1
   48 lrwxrwxrwx  1 root root       9 Aug 26 12:28 synergy-core.log -> /dev/null
   38 -rw-r--r--  1 root root  621785 Aug 31 15:08 synergy-router.log
   17 -rw-r--r--  1 root root 1048500 Aug 31 14:40 synergy-router.log.1
 1351 lrwxrwxrwx  1 root root       9 Aug 26 12:28 synergy-service.log -> /dev/null
pi@JojosRPi3-1:/var/log/synergy $

Da hat synergy vohl die Datei (und damit den Link) gelöscht und wieder 
neu aufgemacht :(
Auch wenn das eine Beta Version ist und die Entwickler im Fehlerfall 
gerne die logs haben möchten, so ist das ein SDC Killer.

Und gerade sind der Kofler für Linux und Raspberry gekommen, hoffe die 
bringen auch etwas mehr Erleuchtung. Das Halbwissen aus den unzähligen 
Blogs ist nicht das Wahre.

[DPA (Gast)]

Johannes S. schrieb:
> Da hat synergy vohl die Datei (und damit den Link) gelöscht und wieder
> neu aufgemacht

Könnte auch logrotate sein.

[Joachim B. (jar)]

Johannes S. schrieb:
> Danke an Sheeva und WTF und die anderen für die Hilfe.

ja wobei das echt unübersichtlich wird

> Bitte locker bleiben, der lange Thread ist einfach etwas unübersichtlich
> geworden, natürlich auch weil ich mit meiner synergy 2.x dazugekommen
> bin.
> Also Joachim: Raspbian Jessie, synergy 1.x,
> ich: Raspbian Stretch, synergy 2.x

nicht nur wegen Synergy 1 vs. 2 und jessie vs. stretch

> Zum logger: auf Stretch läuft rsyslog als service, bei Jessie müsste das
> auch schon so sein.

schaue ich nach, aber ich bin schon sovielen Hilfewilligen ohne Erfog 
nachgerannt das ich es nicht mehr grundsätzlich mache weil
Raspbian ist nicht Linux und alles kann man nicht verallgemeinern und 
übernehmen

> Und das synergy 2 loggt wie blöde. Es werden log Dateien in

synergy1 auch und wie schon geschrieben an viele Stellen.

> Da hat synergy vohl die Datei (und damit den Link) gelöscht und wieder
> neu aufgemacht :(
> Auch wenn das eine Beta Version ist und die Entwickler im Fehlerfall
> gerne die logs haben möchten, so ist das ein SDC Killer.

> Das Halbwissen aus den unzähligen
> Blogs ist nicht das Wahre.

und das Halbwissen um Raspbian auch nicht!

Ich würde immer noch gerne statt die Logs zu löschen nur die 
Synergyeinträge raushaben und die Logs auf letzte 100 Zeilen begrenzen 
und Schreibvorgänge der LOGs in der RAMDISK haben und natürlich keine 
compressed Versionen.

Das muss ich nun Stück für Stück aufdröseln und angehen.

[Bernd K. (prof7bit)]

Joachim B. schrieb:
> Ich würde immer noch gerne statt die Logs zu löschen nur die
> Synergyeinträge raushaben

Schau mal in die Konfig-Dateien in /etc/rsyslog.d/ und lass Dich 
inspirieren. Dort kann man ansetzen.

[Egon D. (Gast)]

Johannes S. schrieb:

> Da hat synergy vohl die Datei (und damit den Link)
> gelöscht und wieder neu aufgemacht :(

Hmm. Idiotisch.

Du könntest natürlich versuchen, den nächstgrößeren Hammer
zu nehmen und /var/log/synergy als Ganzes auf /dev/null
zu verlinken :O)

[wtf? (Gast)]

Johannes S. schrieb:

> Da hat synergy vohl die Datei (und damit den Link) gelöscht und wieder
> neu aufgemacht :(



Welches filesystem? Verpass soch dem link wenn es ansonsten so 
funktioniert wie du es haben willst ggf. einfach ein immutable-flag, 
"auf unveränderbar setzen"

chattr +i

[Johannes S. (Gast)]

Ja, werde die letzten beiden Tipps morgen testen.

[wtf? (Gast)]

wtf? schrieb:
> Johannes S. schrieb:
>
>> Da hat synergy vohl die Datei (und damit den Link) gelöscht und wieder
>> neu aufgemacht :(
>
>
>
> Welches filesystem? Verpass soch dem link wenn es ansonsten so
> funktioniert wie du es haben willst ggf. einfach ein immutable-flag,
> "auf unveränderbar setzen"
>
> chattr +i

Nö, scheint mit links nicht zu funktionieren, sorry.

chattr: Operation not supported while reading flags on ...
wäre ja auch zu einfach gewesen ;)

[wtf? (Gast)]

> Nö, scheint mit links nicht zu funktionieren, sorry.
>
> chattr: Operation not supported while reading flags on ...
> wäre ja auch zu einfach gewesen ;)


Andererseits ist das aber auch Egal. ;)

Anstelle des symbolischen links einfach einer regulären Datei das flag 
setzen. Das sollte funktionieren.

touch synergywhatever.log
chattr +i synergywhatever.log


Die Datei wird so bleiben wie sie ist, leer.
Falls dein Filesystem das unterstützt.

[Daniel A. (daniel-a)]

Egon D. schrieb:
> /var/log/synergy als Ganzes auf /dev/null zu verlinken

Das geht nicht, dann würde ein Open auf /var/log/synergy/whatever mit 
ENOTDIR fehlschlagen.

Ich habe mal schnell ein kleines fuse filesystem geschrieben, welches 
über ein Verzeichnis gemountet werden kann, in dem dann entweder jedes 
stat/open ein Symlink ist, oder eine Datei, bei welcher 
Schreiboperationen an stdin eines beliebigen sh Kommandos gesendet 
werden kann. Damit müsste man einigen Programmen, die nicht den System 
logger verwenden, zuleibe rücken können. Es ist im Anhang zu finden. Um 
es zu verwenden muss man erst libfuse-dev, libfuse2 und gcc 
installieren. Dann kompilieren:

gcc -std=c11 -Wall -Wextra -pedantic -Werror  -lfuse src/redirfs.c -o redirfs

Danach kann man es so verwenden:

Nach /dev/null:

./redirfs -o target='/dev/null' /var/log/synergy/

In das logfile /var/log/my_synergy.log:

./redirfs -o target='/var/log/my_synergy.log' /var/log/synergy/

Zum Systemlogger senden:

./redirfs -o target='|logger' /var/log/synergy/

Mit ein paar zusatzinformationen zum Systemlogger senden:

./redirfs -o target='|logger --rfc5424 --sd-id redirfs@1 --sd-param dir=\\"synergy\\" --sd-param file="\\"$FILE\\""' /var/log/synergy/

Vorher ein paar Zeilen herausfiltern, dann zum logger:

./redirfs -o target='|grep -vi synergy | logger' /var/log/synergy/

Vorher ein paar Zeilen herausfiltern, dann in Datei mit selbem Namen in 
anderem Verzeichnis:

./redirfs -o target='|grep -vi synergy > "/var/log/my_synergy_logs/$FILE"' /var/log/synergy/

etc.

Es ist aber nur etwas, dass ich schnell schnell zusammengehackt habe. 
Das erstellen von Unterverzeichnissen und das mounten einzelner Dateien 
wird noch nicht unterstützt, und ich habe das ganze noch nicht viel 
getestet.

PS: Aufpassen, dass man sich keine Endlosschleife baut (syslog => 
datei/redirfs => logger => syslog => datei/redirfs => usw.).

[Daniel A. (daniel-a)]

Es interessiert vermutlich keinen, aber eine verbesserte Version von 
redirfs ist jetzt auf meinem GitHub Profil:
https://github.com/Daniel-Abrecht/redirfs