Re: ejecución de un cron

[Toni Mas i Soler]

Buenas,
Mírate el fichero /etc/default/cron
La opción EXTRA_OPTS puede contener  opciones adicionales del estilo "-L X"
donde X puede ser, según el man del cron:
   -L loglevel
   Tell cron what to log about jobs (errors are logged
regardless of this value) as the sum of the following values:

   1  will log the start of all cron jobs

   2  will log the end of all cron jobs

   4  will log all failed jobs (exit status != 0)

   8  will log the process number of all cron jobs

   The default is to log the start of all jobs (1).
Logging will be disabled if levels is set to zero (0). A  value  of
   fifteen (15) will select all options.

En tu caso, entiendo que debes informar un 3.
Tienes que rearrancar el demonio cron una vez modificado.

Espero que sea lo que buscas.

Toni Mas

Missatge de miguel angel gonzalez  del dia
dv., 15 de febr. 2019 a les 16:23:
>
> Buenas tardes,
> Os pongo en antecedentes,una máquina por la noche hace unas tareas 
> programadas en cron. Veo en el log tanto en syslog como en /var/log/cron (lo 
> acabo de activar) que sólo registra el inicio de la tarea, pero no el fin. 
> ¿Se ocurre alguna manera de hacerlo?
> Estoy haciendo pruebas de este tipo:
> #35 13  *   *   *   sh /home/parsys/prueba_cron.sh >> 
> /home/parsys/prueba_cron2.out#35 13  *   *   *   sh 
> /home/parsys/prueba_cron.sh >> /home/parsys/prueba_cron2.out#35 13  * 
>   *   *   sh /home/user/prueba_cron.sh >> /home/parsys/ 
> prueba_cron2.out
> En el fichero de salida, sólo muetra la hora de inicio. He puesto una 
> variable llamada date en el script para que me envíe la hora al fichero de 
> salida (prueba_cron2.out), pero nada. Quiero saber cuando finaliza.
> ¿Alguna idea? Muchas gracias de antemano.
> Un saludo.
>
> --
> /m.a.

Re: USB hard drives -- recommendations?

[Toni Mas i Soler]

I bought "Seagate Expansion STEA3000400" to plug in to a Raspberry PI 3. It
don't need extra power suply. I use to backup my data.

Toni Mas


Missatge de local10  del dia dg., 3 de febr. 2019 a
les 1:20:

> On 1/25/19 9:24 AM, James H. H. Lampert wrote:
>
> >> Fellow List members:
> >>
> >> Would anybody care to voice an opinion on USB external hard drives in
> the 2 terabyte size range, for automated backup purposes?
> >>
>
>
> You may want to consider buying an USB HDD enclosure/cradle, like this
> one[1] for example, they are cheap and would allow you to use a regular
> internal HDD as a USB drive. I use similar scheme for my own backups, it
> works reasonably well.
>
> Regards,
>
>
> [1] - https://www.ebay.com/itm/253631205544 <
> https://www.ebay.com/itm/253631205544>
>
>

Re: (deb-cat) Recuperar directoris

[Toni Mas i Soler]

Hola,
He hegut d'invocar ssh amb la opció -tt, amb una sola -t encara no en
fucnionava. Moltes gràcies!

Toni Mas


Missatge de Alex Muntada  del dia dl., 3 de des. 2018 a
les 11:28:

> Hola Toni,
>
> > El cas és que si intento executar fsck  -vMsrp -t ext 4 sobre
> > la UUID i a través de SSH de la partició que vull revisar em
> > dóna error (return code 8). No em dóna més informació. En canvi,
> > la mateixa sentència executada amb una terminal interactiva no
> > em dóna cap problema.
>
> Prova a passar l'opció -t a l'ssh perquè reservi un tty. Si el
> fsck espera una resposta interactiva, segons com cridis l'ssh
> no es reserva cap tty i aleshores falla.
>
> Salut,
> Alex
>
> --
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁  Alex Muntada 
>   ⢿⡄⠘⠷⠚⠋   Debian Developer - log.alexm.org
>   ⠈⠳⣄
>
>

Re: (deb-cat) Recuperar directoris

[Toni Mas i Soler]

Ara ho he vist. Buscava al "man fsck" i no trobava la opció.

Ja que hi som, llanço una consulta. Tinc configurat un sistema de backup
amb un Raspberry PI (raspbian stable+debian armhf stable) al quan accedeixo
remotament via SSH. Totes les gestions de manteniment personalitzades (que
no venen per defecte) les executo mitjançant script  BASH a través de SSH
--una forma que em resulta pràctica per què centralitzo el manteniment--.

El cas és que si intento executar fsck  -vMsrp -t ext 4 sobre la UUID  i a
través de SSH de la partició que vull revisar em dóna error (return code
8). No em dóna més informació. En canvi, la mateixa sentència executada amb
una terminal interactiva no em dóna cap problema. Vull creure que és degut
a alguna variable d'entorn. Però no sé per on continuar amb la
investigació. Alguna idea?

Gràcies.
Toni Mas


Missatge de Jordi Funollet  del dia dj., 29 de nov.
2018 a les 10:15:

> Hola Toni,
>
> has de buscar a 'man fsck.ext3', que té opcions específiques per aquest
> filesystem. 'man fsck' sols t'ensenyarà les opcions comunes a tots els
> filesystems.
>
> --
> Jordi Funollet Pujol
> http://www.linkedin.com/in/jordifunollet
>
> On Thu, Nov 29, 2018, at 9:50 AM, Toni Mas i Soler wrote:
> > Hola,
> > Disculpeu la ignorància. Per curiositat. No he trobat en cap documentació
> > el què implica la opció -cc del fsck (doble). Algú sap què és el seu
> > significat exacte?
> >
> > Gràcies.
> > Toni Mas
> >
> >
> > Missatge de Narcis Garcia  del dia dt., 27 de
> nov.
> > 2018 a les 15:06:
> >
> > > __
> > > I'm using this express-made address because personal addresses aren't
> > > masked enough at this mail public archive. Public archive administrator
> > > should fix this against automated addresses collectors.
> > > On 27/11/18 14:49, Eloi wrote:
> > > > El 27/11/18 a les 09:48, Narcis Garcia ha escrit:
> > > >> [...]
> > > >> El què vaig fer és reiniciar a una unitat externa i:
> > > >> $ fsck -ccyk /dev/sda1
> > > >
> > > > Uf. A banda de la recomanació que ja t'han fet de ddrescue per treure
> > > > una imatge del disc, fer un fsck -cc sobre un disc que dóna errors i
> > > > conté dades a recuperar és una *terrible* idea. La prova "no
> destructiva
> > > > de lectura i escriptura" de badblocks consisteix a llegir un sector,
> > > > guardar-lo en memòria, escriure noves dades, llegir-les, verificar
> que
> > > > són les que just ha escrit i reescriure les dades originals.
> > > >
> > > > Ja no és només risc inherent d'escriure sobre un disc que ja ha donat
> > > > indicis de fallada (raó per la qual és recomanable sempre muntar en
> > > > només lectura particions de discs amb danys si no és possible un
> > > > ddrescue), el fet de sobreescriure sobre *tots* els sectors pot
> haver no
> > > > només augmentat els errors de lectura sinó haver destruït dades fins
> > > > aleshores recuperables en cas que el cicle de llegir, escriure,
> > > > comprovar i sobreescriure amb les dades originals falli en els últims
> > > > passos.
> > > >
> > > > No puc ajudar-te en l'aspecte de recuperar directoris, només puc
> dir-te
> > > > que no tornis a fer un fsck -cc sobre un disc amb errors i dades a
> > > > recuperar. El que faria ara, per no agreujar encara més la situació,
> > > > seria crear amb ddrescue una imatge del disc i fer servir eines de
> > > > rescat sobre *còpies* d'aquesta imatge que has creat. El problema és
> que
> > > > fer-ho sobre segur suposa disposar d'un mínim de 2x l'espai del disc
> > > > original.
> > > >
> > >
> > > Vaig fer la revisió de lectura+escriptura perquè he llegit que el
> > > sistema SMART només reubica sectors quan falla l'escriptoria, i volia
> > > poder copiar-me les dades (corruptes o no) sense que s'interrompés res
> > > per fallades de lectura. També la meva intenció era que el fsck fes la
> > > seva reubicació de blocs; no m'importa gaire que es perdin fitxers
> d'uns
> > > quants blocs defectuosos; m'importa el conjunt de centenars de milers.
> > >
> > > No disposo d'espai per jugar amb una partició de 3TiB
> > > La meva esperança és només recuperar algunes eestructures d'inodes.
> > >
> > > Crec que el problema amb fsck ha estat més lògic que físic: els inodes
> > > illegibles (i orfes) deuen haver estat «matxacats». Però... sorpresa!
> > > dins de /lost+found hi han anat a parar centenars de milers de
> > > directoris i fitxers!
> > >
> > >
>
>

Re: (deb-cat) Recuperar directoris

[Toni Mas i Soler]

Hola,
Disculpeu la ignorància. Per curiositat. No he trobat en cap documentació
el què implica la opció -cc del fsck (doble). Algú sap què és el seu
significat exacte?

Gràcies.
Toni Mas


Missatge de Narcis Garcia  del dia dt., 27 de nov.
2018 a les 15:06:

> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> On 27/11/18 14:49, Eloi wrote:
> > El 27/11/18 a les 09:48, Narcis Garcia ha escrit:
> >> [...]
> >> El què vaig fer és reiniciar a una unitat externa i:
> >> $ fsck -ccyk /dev/sda1
> >
> > Uf. A banda de la recomanació que ja t'han fet de ddrescue per treure
> > una imatge del disc, fer un fsck -cc sobre un disc que dóna errors i
> > conté dades a recuperar és una *terrible* idea. La prova "no destructiva
> > de lectura i escriptura" de badblocks consisteix a llegir un sector,
> > guardar-lo en memòria, escriure noves dades, llegir-les, verificar que
> > són les que just ha escrit i reescriure les dades originals.
> >
> > Ja no és només risc inherent d'escriure sobre un disc que ja ha donat
> > indicis de fallada (raó per la qual és recomanable sempre muntar en
> > només lectura particions de discs amb danys si no és possible un
> > ddrescue), el fet de sobreescriure sobre *tots* els sectors pot haver no
> > només augmentat els errors de lectura sinó haver destruït dades fins
> > aleshores recuperables en cas que el cicle de llegir, escriure,
> > comprovar i sobreescriure amb les dades originals falli en els últims
> > passos.
> >
> > No puc ajudar-te en l'aspecte de recuperar directoris, només puc dir-te
> > que no tornis a fer un fsck -cc sobre un disc amb errors i dades a
> > recuperar. El que faria ara, per no agreujar encara més la situació,
> > seria crear amb ddrescue una imatge del disc i fer servir eines de
> > rescat sobre *còpies* d'aquesta imatge que has creat. El problema és que
> > fer-ho sobre segur suposa disposar d'un mínim de 2x l'espai del disc
> > original.
> >
>
> Vaig fer la revisió de lectura+escriptura perquè he llegit que el
> sistema SMART només reubica sectors quan falla l'escriptoria, i volia
> poder copiar-me les dades (corruptes o no) sense que s'interrompés res
> per fallades de lectura. També la meva intenció era que el fsck fes la
> seva reubicació de blocs; no m'importa gaire que es perdin fitxers d'uns
> quants blocs defectuosos; m'importa el conjunt de centenars de milers.
>
> No disposo d'espai per jugar amb una partició de 3TiB
> La meva esperança és només recuperar algunes eestructures d'inodes.
>
> Crec que el problema amb fsck ha estat més lògic que físic: els inodes
> illegibles (i orfes) deuen haver estat «matxacats». Però... sorpresa!
> dins de /lost+found hi han anat a parar centenars de milers de
> directoris i fitxers!
>
>

Re: gnats user

[Toni Mas i Soler]

I removed it yesterday, too.

No problems at the moment.

Toni Mas

2018-03-07 20:13 GMT+01:00 :

> On Wednesday, March 07, 2018 01:16:06 AM Reco wrote:
> > Along with other uid<100 users, 'gnats' is there for a long time,
> > nobody's sure what will break if it's removed from passwd(5),
>
> Wow!  (I am not the OP, but that is disappointing (but not surprising, I
> suspect the same or similar about other things buried in Linux one place or
> another) and scary.
>
> > and it's
> > not that someone will use uid=41 for anything else.
>
>

Re: Q: RAID1 and chunk size

[Toni Mas i Soler]

I think it has no mean in RAID1 mode. It is used in RAID0,4,5,6,10 modes.

You can see in man mdadm.



Toni Mas

2018-03-07 23:06 GMT+01:00 Darac Marjal :

>
>
> On 07/03/18 21:13, Steve Keller wrote:
> > I have a RAID1 array with 2 disks (/dev/sda1 and /dev/sdb1) of 2 TB
> > each.  By running mdadm -X /dev/sda1 I see that the chunk size is 64 MB:
> >
> > # mdadm -X /dev/sda1
> > Filename : /dev/sda1
> > Magic : 6d746962
> > Version : 4
> > UUID : 300551ed:f6690dfb:1c939898:af5509c6
> > Events : 257
> > Events Cleared : 257
> > State : OK
> > Chunksize : 64 MB
> > Daemon : 5s flush period
> > Write Mode : Normal
> > Sync Size : 1953381376 (1862.89 GiB 2000.26 GB)
> > Bitmap : 29807 bits (chunks), 2 dirty (0.0%)
> >
> > What exactly does the chunk sized mean?  My question is how reads and
> > writes on an array are done.  Will the kernel always read or write a
> > complete chunk?  If so, does that mean that writing a single 4 KB
> > block to a file system will cause a 64 MB read, i.e one chunk, change
> > the 4 KB block in that chunk and write back the 64 MB chunk?
>
> Yes, my understanding is that chunk size is the size of area upon which
> parity is calculated, or the size of data which is allocated before
> moving onto the next drive etc.
>
> My guess, though, is that there is a balance to be struck. Yes, if the
> chunk size is small, then there is very little write amplification. But
> if the chunk size is too small, then you need to wait for that chunk to
> pass the read-write head again, you need to be switching between sectors
> very often etc. With a bigger chunk, you can take better advantage of
> caching. These days, 64Mb is a relatively small amount to pull into a
> buffer, it can be pulled in, modified and rewritten virtually
> instantanously.
>
> There's a nice article on the effect of different chunk sizes here:
> http://louwrentius.com/linux-raid-level-and-chunk-size-the-benchmarks.html
>
> >
> > Wouldn't that mean a massive performance problem?
> >
> > Steve
> >
>
>
>

Re: (deb-cat) Sticky-enganxos pel propietari de directori

[Toni Mas i Soler]

O no entenc exactament el què proposes o no sóc capaç d'imaginar-me ara
mateix un cas d'ús que em pogués suposar una millora.
Només per donar-hi voltes. Podries aportar un cas d'ús o fos interessant
aquest comportament.

Personalment, un canvi així, em suposaria un gran esforç per
interioritzar-lo i aplicar-lo al meu sistema, a més de la por que sempre
m'han fet els permisos +s.

Salutacions,

Toni Mas

El dia 26 de novembre de 2017 a les 11:27, Narcis Garcia <
debianli...@actiu.net> ha escrit:

> No sé si aquesta falta de funcionalitat depèn del nucli (com Linux) o de
> les eines GNU.
> M'agradaria proposar on sigui escaient que, l'atribut +s pel propietari
> d'un directori tingui el següent efecte enganxós:
> Que el grup dels nous elements creats a dins hereti els permisos de grup.
> Això tant pot millorar l'accés a fitxers, tant a les memòries USB, com a
> carpetes compartides entre usuaris que tinguin diferent «umask».
>
> Algú sap on seria el millor loc per fer aquesta proposta?
>
> Gràcies.
>
>
>
>
> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 26/11/17 a les 10:54, Narcis Garcia ha escrit:
> > https://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories
> >
> > Ja veig que les respostes són:
> > No.
> > Si.
> >
> >
> >
> >
> >
> > __
> > I'm using this express-made address because personal addresses aren't
> > masked enough at this mail public archive. Public archive administrator
> > should fix this against automated addresses collectors.
> > El 26/11/17 a les 10:41, Narcis Garcia ha escrit:
> >> No té cap efecte sobre futurs continguts d'un directori aquesta
> instrucció?
> >> $ chmod u+s LaMevaCarpeta
> >>
> >> Si la resposta és «no»; Es tracta d'un disseny incomplet de GNU o Unix?
> >>
> >> Gràcies.
> >>
> >
>
>