Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #234782 > unrolled thread

repeated system mail, /etc/.pwd.lock ?

Back to article view | Back to linux.debian.user

Contents

  repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-04 08:20 +0200
    Re: repeated system mail, /etc/.pwd.lock ? Darac Marjal <mailinglist@darac.org.uk> - 2021-05-04 10:10 +0200
      Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-04 10:20 +0200
      Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-04 11:20 +0200
        Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-05 00:50 +0200
        Re: repeated system mail, /etc/.pwd.lock ? Kushal Kumaran <kushal@locationd.net> - 2021-05-05 03:10 +0200
          Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-05 03:20 +0200
            Re: repeated system mail, /etc/.pwd.lock ? Greg Wooledge <greg@wooledge.org> - 2021-05-05 03:40 +0200
            Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-05 04:40 +0200
            Re: repeated system mail, /etc/.pwd.lock ? David Wright <deblis@lionunicorn.co.uk> - 2021-05-05 04:40 +0200
              Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-05 04:50 +0200
                Re: repeated system mail, /etc/.pwd.lock ? David Wright <deblis@lionunicorn.co.uk> - 2021-05-05 05:10 +0200
                  Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-05 05:20 +0200
              Re: repeated system mail, /etc/.pwd.lock ? Greg Wooledge <greg@wooledge.org> - 2021-05-05 13:30 +0200
                Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-05 16:00 +0200
                  Re: repeated system mail, /etc/.pwd.lock ? Jonathan Dowland <jon+debian-user@dow.land> - 2021-05-08 09:30 +0200
                    Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-09 05:10 +0200
                Re: repeated system mail, /etc/.pwd.lock ? David Wright <deblis@lionunicorn.co.uk> - 2021-05-05 17:40 +0200
                  Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-05 18:00 +0200
                  Re: repeated system mail, /etc/.pwd.lock ? Greg Wooledge <greg@wooledge.org> - 2021-05-05 18:10 +0200
                    Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-05 21:30 +0200
                    Re: repeated system mail, /etc/.pwd.lock ? David Wright <deblis@lionunicorn.co.uk> - 2021-05-06 05:30 +0200
                  Re: repeated system mail, /etc/.pwd.lock ? Charles Curley <charlescurley@charlescurley.com> - 2021-05-06 04:50 +0200
                  Re: repeated system mail, /etc/.pwd.lock ? davidson <davidson@freevolt.org> - 2021-05-06 16:00 +0200
                    OT: dotfile generalities (was Re: repeated system mail, /etc/.pwd.lock  ?) davidson <davidson@freevolt.org> - 2021-05-06 16:40 +0200
                      Re: OT: dotfile generalities (was Re: repeated system mail,  /etc/.pwd.lock ?) Greg Wooledge <greg@wooledge.org> - 2021-05-06 16:50 +0200
                        Re: OT: dotfile generalities (was Re: repeated system mail,  /etc/.pwd.lock ?) David Wright <deblis@lionunicorn.co.uk> - 2021-05-07 06:30 +0200
                          Re: OT: dotfile generalities (was Re: repeated system mail,  /etc/.pwd.lock ?) <tomas@tuxteam.de> - 2021-05-07 09:40 +0200
                            Re: OT: dotfile generalities (was Re: repeated system mail,  /etc/.pwd.lock ?) Tixy <tixy@yxit.co.uk> - 2021-05-07 10:50 +0200
                              Re: OT: dotfile generalities (was Re: repeated system mail,  /etc/.pwd.lock ?) <tomas@tuxteam.de> - 2021-05-07 11:20 +0200
                Re: repeated system mail, /etc/.pwd.lock ? David Wright <deblis@lionunicorn.co.uk> - 2021-05-09 06:20 +0200
                  Re: repeated system mail, /etc/.pwd.lock ? Emanuel Berg <moasenwood@zoho.eu> - 2021-05-09 12:00 +0200

Page 1 of 2  [1] 2  Next page →

#234782 — repeated system mail, /etc/.pwd.lock ?

I get system mail all the time - I've got 2757 at the moment -
that tells me that

  [ 4/Apr/2021 22:11:33]
  IN_CLOSE_WRITE /etc/.pwd.lock
  * /etc/.pwd.lock is closed

Any clues what that problem might be?

TIA

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [next] | [standalone]

#234787

[Multipart message — attachments visible in raw view] — view raw

On 04/05/2021 07:12, Emanuel Berg wrote:
> I get system mail all the time - I've got 2757 at the moment -
> that tells me that
>
>   [ 4/Apr/2021 22:11:33]
>   IN_CLOSE_WRITE /etc/.pwd.lock
>   * /etc/.pwd.lock is closed
>
> Any clues what that problem might be?
The "IN_" prefix tells you that this is an inotify event. IN_CLOSE_WRITE
fires when a process _had_ the specified file open for writing, but has
just closed it. Perhaps you have an "incron" job somewhere?
>
> TIA
>

[toc] | [prev] | [next] | [standalone]

#234789

Darac Marjal wrote:

>> I get system mail all the time - I've got 2757 at the
>> moment - that tells me that
>>
>>   [ 4/Apr/2021 22:11:33]
>>   IN_CLOSE_WRITE /etc/.pwd.lock
>>   * /etc/.pwd.lock is closed
>>
>> Any clues what that problem might be?
>
> The "IN_" prefix tells you that this is an inotify event.
> IN_CLOSE_WRITE fires when a process _had_ the specified file
> open for writing, but has just closed it. Perhaps you have
> an "incron" job somewhere?

I don't know, how do I find out?

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#234797

Darac Marjal wrote:

> The "IN_" prefix tells you that this is an inotify event.
> IN_CLOSE_WRITE fires when a process _had_ the specified file
> open for writing, but has just closed it. Perhaps you have
> an "incron" job somewhere?

I have cron do two very short scripts every @midnight, these
run fine individually and I've not experienced any problems at
00:00 so I take it they run fine there as well.

Other than that I have not fiddled with cronjobs at all,
I think. (?)

This is what 'ps -e' tells me:

 9 ~/ppl/mats ps -e
    PID TTY          TIME CMD
      1 ?        00:00:26 systemd
      2 ?        00:00:00 kthreadd
      3 ?        00:00:00 rcu_gp
      4 ?        00:00:00 rcu_par_gp
      6 ?        00:00:00 kworker/0:0H-kblockd
      8 ?        00:00:00 mm_percpu_wq
      9 ?        00:00:01 ksoftirqd/0
     10 ?        00:00:28 rcu_sched
     11 ?        00:00:00 rcu_bh
     12 ?        00:00:00 migration/0
     14 ?        00:00:00 cpuhp/0
     15 ?        00:00:00 cpuhp/1
     16 ?        00:00:00 migration/1
     17 ?        00:00:00 ksoftirqd/1
     19 ?        00:00:00 kworker/1:0H-kblockd
     20 ?        00:00:00 cpuhp/2
     21 ?        00:00:00 migration/2
     22 ?        00:00:01 ksoftirqd/2
     24 ?        00:00:00 kworker/2:0H-kblockd
     25 ?        00:00:00 cpuhp/3
     26 ?        00:00:00 migration/3
     27 ?        00:00:00 ksoftirqd/3
     29 ?        00:00:00 kworker/3:0H-kblockd
     30 ?        00:00:00 kdevtmpfs
     31 ?        00:00:00 netns
     32 ?        00:00:00 kauditd
     35 ?        00:00:00 khungtaskd
     36 ?        00:00:00 oom_reaper
     37 ?        00:00:00 writeback
     38 ?        00:00:00 kcompactd0
     39 ?        00:00:00 ksmd
     40 ?        00:00:01 khugepaged
     41 ?        00:00:00 crypto
     42 ?        00:00:00 kintegrityd
     43 ?        00:00:00 kblockd
     44 ?        00:00:00 edac-poller
     46 ?        00:00:00 devfreq_wq
     47 ?        00:00:00 watchdogd
     49 ?        00:00:00 irq/25-AMD-Vi
     50 ?        00:00:05 kswapd0
     68 ?        00:00:00 kthrotld
     70 ?        00:00:00 amd_iommu_v2
     71 ?        00:00:00 ipv6_addrconf
     80 ?        00:00:00 kstrp
    132 ?        00:00:00 nvme-wq
    133 ?        00:00:00 nvme-reset-wq
    134 ?        00:00:00 nvme-delete-wq
    147 ?        00:00:00 ata_sff
    148 ?        00:00:00 scsi_eh_0
    149 ?        00:00:00 scsi_tmf_0
    150 ?        00:00:00 scsi_eh_1
    151 ?        00:00:00 scsi_tmf_1
    153 ?        00:00:00 scsi_eh_2
    154 ?        00:00:00 scsi_tmf_2
    155 ?        00:00:00 scsi_eh_3
    156 ?        00:00:00 scsi_tmf_3
    157 ?        00:00:00 scsi_eh_4
    158 ?        00:00:00 scsi_tmf_4
    159 ?        00:00:00 scsi_eh_5
    160 ?        00:00:00 scsi_tmf_5
    161 ?        00:00:00 scsi_eh_6
    162 ?        00:00:00 scsi_tmf_6
    163 ?        00:00:00 scsi_eh_7
    164 ?        00:00:00 scsi_tmf_7
    167 ?        00:00:00 scsi_eh_8
    168 ?        00:00:00 scsi_tmf_8
    229 ?        00:00:00 kworker/2:1H-kblockd
    231 ?        00:00:00 kworker/3:1H-kblockd
    240 ?        00:00:00 md
    250 ?        00:00:00 raid5wq
    285 ?        00:00:00 kworker/1:1H-kblockd
    304 ?        00:00:00 kworker/u65:0
    305 ?        00:00:02 jbd2/sda2-8
    306 ?        00:00:00 ext4-rsv-conver
    307 ?        00:00:00 kworker/0:1H-kblockd
    371 ?        00:00:02 systemd-journal
    407 ?        00:00:00 systemd-udevd
    410 ?        00:00:00 loop0
    411 ?        00:00:00 loop1
    414 ?        00:00:00 loop2
    415 ?        00:00:00 loop3
    417 ?        00:00:00 loop4
    472 ?        00:00:00 led_workqueue
    475 ?        00:00:00 nvkm-disp
    515 ?        00:00:00 ttm_swap
    590 ?        00:00:00 dhclient
    591 ?        00:00:00 rpcbind
    592 ?        00:00:02 systemd-resolve
    596 ?        00:00:00 accounts-daemon
    598 ?        00:00:03 dbus-daemon
    599 ?        00:00:02 NetworkManager
    605 ?        00:00:07 snapd
    606 ?        00:00:18 systemd-logind
    608 ?        00:00:00 usbguard-dbus
    665 ?        00:00:01 usbguard-daemon
    713 ?        00:00:00 polkitd
    724 ?        00:00:11 ntpd
    726 ?        00:00:00 sshd
    741 tty1     00:00:00 login
   1130 ?        00:00:00 exim4
   1149 ?        00:00:00 iwatch
   1162 ?        00:00:00 systemd
   1163 ?        00:00:00 (sd-pam)
   1190 ?        00:00:01 pipewire
   1191 ?        00:07:31 pulseaudio
   1193 ?        00:00:02 tracker-miner-f
   1194 tty1     00:00:00 zsh
   1197 ?        00:00:07 dbus-daemon
   1206 ?        00:00:00 pipewire-media-
   1210 ?        00:00:00 upowerd
   1254 tty1     00:08:35 emacs
   1351 ?        00:00:41 tmux: server
   1422 tty6     00:00:00 login
   1431 tty6     00:00:00 zsh
   1444 tty6     00:00:00 startx
   1478 tty6     00:00:00 xinit
   1479 tty6     00:04:21 Xorg
   1519 tty6     00:00:00 sh
   1525 tty6     00:00:00 openbsd-cwm
   1532 tty6     00:00:10 xterm
   1533 pts/2    00:00:00 tmux: client
   1534 pts/3    00:00:00 zsh
   1580 tty3     00:00:00 login
   1582 tty5     00:00:00 login
   2089 tty3     00:00:00 zsh
   2102 tty3     00:00:00 tmux: client
   2103 pts/5    00:00:00 zsh
   2105 pts/6    00:00:00 zsh
   2173 pts/5    00:00:00 ssh
   2176 ?        00:00:00 ssh
   4197 tty5     00:00:00 zsh
  15493 pts/8    00:00:00 ssh
  24374 pts/9    00:00:00 zsh
  24435 tty2     00:00:00 login
  24442 tty2     00:00:00 zsh
  24455 tty2     00:00:00 tmux: client
  24456 pts/0    00:00:00 zsh
  24458 pts/1    00:00:00 zsh
  24513 tty4     00:00:00 login
  24520 tty4     00:00:00 zsh
  24533 tty4     00:00:00 tmux: client
  24534 pts/7    00:00:00 zsh
  35438 ?        00:00:01 packagekitd
  49811 pts/10   00:00:00 zsh
  61886 ?        00:00:00 at-spi-bus-laun
  68488 pts/11   00:00:00 zsh
  68591 pts/3    00:00:00 play
  68593 pts/3    00:05:21 mpv
  69896 pts/7    00:00:17 rtorrent main
 105953 ?        00:00:00 ispell
 119970 pts/4    00:00:00 zsh
 120776 ?        00:00:04 kworker/3:0-events
 121785 ?        00:00:00 tracker-store
 123926 pts/4    00:00:00 play
 123928 pts/4    00:11:41 mpv
 126051 ?        00:00:02 kworker/0:2-events
 126912 ?        00:00:00 kworker/0:1-events
 129245 ?        00:00:01 kworker/1:0-events
 130025 ?        00:00:06 kworker/u64:1-events_unbound
 130067 ?        00:00:00 xsel
 131065 ?        00:00:00 kworker/3:2-events
 131230 ?        00:00:00 kworker/2:0-events
 131466 ?        00:00:00 kworker/1:1
 131469 ?        00:00:00 kworker/2:1-events
 131470 ?        00:00:00 kworker/u64:0-events_unbound
 131472 ?        00:00:00 kworker/2:2-events
 131480 ?        00:00:00 tumblerd
 131494 ?        00:00:00 kworker/0:0-events
 131495 ?        00:00:00 kworker/u64:2
 131589 pts/9    00:00:00 ps

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#234834

>> The "IN_" prefix tells you that this is an inotify event.
>> IN_CLOSE_WRITE fires when a process _had_ the specified
>> file open for writing, but has just closed it. Perhaps you
>> have an "incron" job somewhere?
>
> I have cron do two very short scripts every @midnight, these
> run fine individually and I've not experienced any problems
> at 00:00 so I take it they run fine there as well.
>
> Other than that I have not fiddled with cronjobs at all,
> I think. (?)

No one has any clue how to debug this? Really?

How about directing all them mails to /dev/disintegrate then?

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#234837

On Tue, May 04 2021 at 11:11:02 AM, Emanuel Berg <moasenwood@zoho.eu> wrote:
> Darac Marjal wrote:
>
>> The "IN_" prefix tells you that this is an inotify event.
>> IN_CLOSE_WRITE fires when a process _had_ the specified file
>> open for writing, but has just closed it. Perhaps you have
>> an "incron" job somewhere?
>
> I have cron do two very short scripts every @midnight, these
> run fine individually and I've not experienced any problems at
> 00:00 so I take it they run fine there as well.
>
> Other than that I have not fiddled with cronjobs at all,
> I think. (?)
>
> This is what 'ps -e' tells me:
>
>  9 ~/ppl/mats ps -e
>     PID TTY          TIME CMD
> ... snip
>    1149 ?        00:00:00 iwatch
> ... snip

The manpage at
https://manpages.debian.org/buster/iwatch/iwatch.1.en.html shows log
output similar to what you see.  Check your iwatch configuration and see
what it is doing.

-- 
regards,
kushal

[toc] | [prev] | [next] | [standalone]

#234838

Kushal Kumaran wrote:

> The manpage at
> https://manpages.debian.org/buster/iwatch/iwatch.1.en.html
> shows log output similar to what you see. Check your iwatch
> configuration and see what it is doing.

Thanks, but I've never heard of iwatch, so I haven't mucked
around with its config file. But OK, here it is

<?xml version="1.0" ?>
<!DOCTYPE config SYSTEM "/etc/iwatch/iwatch.dtd" >

<config charset="utf-8">
  <guard email="iwatch@localhost" name="iWatch"/>
  <watchlist>
    <title>Operating System</title>
    <contactpoint email="root@localhost" name="Administrator"/>
    <path type="single" syslog="on">/bin</path>
    <path type="single" syslog="on">/sbin</path>
    <path type="single">/etc</path>
    <path type="recursive">/lib</path>
    <path type="exception">/lib/modules</path>
  </watchlist>
</config>

Does that say anything to you?

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#234839

On Wed, May 05, 2021 at 03:11:53AM +0200, Emanuel Berg wrote:
> Kushal Kumaran wrote:
> > The manpage at
> > https://manpages.debian.org/buster/iwatch/iwatch.1.en.html
> > shows log output similar to what you see. Check your iwatch
> > configuration and see what it is doing.
> 
> Thanks, but I've never heard of iwatch, so I haven't mucked
> around with its config file. But OK, here it is
> 
>   <watchlist>
>     <path type="single">/etc</path>

> Does that say anything to you?

It says that it's watching /etc.  Which is where your file is.  No
surprises here so far.

What you really should be asking is, "What process is using this file,
and why don't I know about it?"

Googling for the file name turns up this:

https://lists.debian.org/debian-user/2005/07/msg02949.html

  The lckpwdf() and ulckpwdf() functions enable modification access to the
  password databases through the lock file. A process first uses lckpwdf() to
  lock the lock file, thereby gaining exclusive rights to modify the
  /etc/passwd or /etc/shadow password database. (See "passwd"  and "shadow" man
  pages.)

  Upon completing modifications, a process should release the lock on the lock
  file using ulckpwdf(). This mechanism prevents simultaneous modification of
  the password databases. The lock file, /etc/.pwd.lock, is used to coordinate
  modification access to the password databases /etc/passwd and /etc/shadow.

So, as one might expect just from the file name, it's a lock file for
the passwd file.

Again, the real question is: What process is touching your passwd file
at this time, and why don't you know about it?

[toc] | [prev] | [next] | [standalone]

#234840

David Wright wrote:

> $ aptitude why iwatch

i   openssh-client         Suggests   monkeysphere                 
i A monkeysphere           Suggests   monkeysphere-validation-agent
i A msva-perl              Provides   monkeysphere-validation-agent
i A msva-perl              Recommends liblinux-inotify2-perl       
i A liblinux-inotify2-perl Suggests   iwatch                       

> $ zgrep -B1 iwatch /var/log/apt/history.log*

/var/log/apt/history.log.2.gz:Requested-By: incal (1000)

/var/log/apt/history.log.2.gz:Install: openvpn:amd64 (2.5.1-1,
automatic), network-manager-openvpn-gnome:amd64 (1.8.12-2,
automatic), python3-appdirs:amd64 (1.4.4-1, automatic),
dnsmasq:amd64 (2.84-1, automatic), ssh-askpass:amd64
(1:1.2.4.1-10+b1, automatic), pcmciautils:amd64 (018-12,
automatic), librygel-renderer-gst-2.6-2:amd64 (0.40.0-1,
automatic), libnet-cidr-perl:amd64 (0.20-1, automatic),
rygel-playbin:amd64 (0.40.0-1, automatic), easy-rsa:amd64
(3.0.8-1, automatic), network-manager-openvpn:amd64 (1.8.12-2,
automatic), libgupnp-dlna-2.0-3:amd64 (0.10.5-4, automatic),
iwatch:amd64 (0.2.2-9, automatic), agent-transfer:amd64
(0.43-3.1, automatic), apg:amd64 (2.2.3.dfsg.1-5+b2,
automatic), network-manager-openconnect-gnome:amd64 (1.2.6-1,
automatic), packagekit-tools:amd64 (1.2.2-2, automatic),
gnome-software:amd64 (3.38.1-1, automatic),
dbus-user-session:amd64 (1.12.20-2, automatic),
libnss-myhostname:amd64 (247.3-3, automatic),
python3-axolotl-curve25519:amd64 (0.4.1.post2-2+b4,
automatic), libstoken1:amd64 (0.92-1, automatic),
libtype-tiny-xs-perl:amd64 (0.022-1, automatic),
malcontent:amd64 (0.10.0-2, automatic), libnl-cli-3-200:amd64
(3.4.0-1+b1, automatic), librygel-core-2.6-2:amd64 (0.40.0-1,
automatic), librygel-ruih-2.0-1:amd64 (0.40.0-1, automatic),
gnome-software-common:amd64 (3.38.1-1, automatic),
libmoox-late-perl:amd64 (0.100-1, automatic),
apt-config-icons-hidpi:amd64 (0.14.2-1, automatic),
usbguard:amd64 (1.0.0+ds-2, automatic), libmutter-7-0:amd64
(3.38.3-5, automatic), rygel-preferences:amd64 (0.40.0-1,
automatic), python3-transitions:amd64 (0.8.6-1, automatic),
pptp-linux:amd64 (1.10.0-1, automatic),
libio-socket-socks-perl:amd64 (0.74-1.1, automatic),
python3-yowsup:amd64 (3.2.3-2, automatic), ufw:amd64
(0.36-7.1, automatic), libcrypt-x509-perl:amd64 (0.53-1,
automatic), libmalcontent-ui-0-0:amd64 (0.10.0-2, automatic),
libxml-stream-perl:amd64 (1.24-4, automatic),
libmalcontent-0-0:amd64 (0.10.0-2, automatic),
gstreamer1.0-clutter-3.0:amd64 (3.0.27-2, automatic),
xdg-desktop-portal-gtk:amd64 (1.8.0-1, automatic),
python3-dissononce:amd64 (0.34.3-2, automatic),
molly-guard:amd64 (0.7.2, automatic), libsnapd-glib1:amd64
(1.58-4, automatic), libostree-1-1:amd64 (2020.8-2,
automatic), libcolorhug2:amd64 (1.4.5-3, automatic),
resolvconf:amd64 (1.87, automatic), vpnc:amd64
(0.5.3+git20210125-1, automatic), wireless-tools:amd64
(30~pre9-13.1, automatic), colord:amd64 (1.4.5-3, automatic),
software-properties-common:amd64 (0.96.20.2-2.1, automatic),
monkeysphere:amd64 (0.43-3.1, automatic), libgsound0:amd64
(1.0.2-5, automatic), libtomcrypt1:amd64 (1.18.2-5,
automatic), openssh-server:amd64 (1:8.4p1-5, automatic),
libio-multiplex-perl:amd64 (1.16-1.1, automatic),
wireless-regdb:amd64 (2020.04.29-2, automatic), pipewire:amd64
(0.3.19-4, automatic), tumbler:amd64 (4.16.0-1, automatic),
libcheese-gtk25:amd64 (3.38.0-3, automatic),
python3-software-properties:amd64 (0.96.20.2-2.1, automatic),
malcontent-gui:amd64 (0.10.0-2, automatic),
librygel-server-2.6-2:amd64 (0.40.0-1, automatic),
libges-1.0-0:amd64 (1.18.3-1, automatic), squashfs-tools:amd64
(1:4.4-2, automatic), yowsup-cli:amd64 (3.2.3-2, automatic),
tumbler-common:amd64 (4.16.0-1, automatic),
mutter-common:amd64 (3.38.3-5, automatic),
gir1.2-packagekitglib-1.0:amd64 (1.2.2-2, automatic),
libusbguard0:amd64 (1.0.0+ds-2, automatic),
network-manager-gnome:amd64 (1.20.0-3, automatic),
libgee-0.8-2:amd64 (0.20.3-1, automatic), libnma-common:amd64
(1.8.30-1, automatic), network-manager-openconnect:amd64
(1.2.6-1, automatic), gnome-settings-daemon-common:amd64
(3.38.1-3, automatic), libappstream4:amd64 (0.14.2-1,
automatic), libnet-server-perl:amd64 (2.009-2, automatic),
appstream:amd64 (0.14.2-1, automatic),
gnome-software-plugin-snap:amd64 (3.38.1-1, automatic),
network-manager-vpnc-gnome:amd64 (1.2.6-3, automatic),
packagekit:amd64 (1.2.2-2, automatic),
libgnupg-interface-perl:amd64 (1.01-2, automatic),
python3-consonance:amd64 (0.1.3-3, automatic),
network-manager-pptp-gnome:amd64 (1.2.8-3+b2, automatic),
libappstream-glib8:amd64 (0.7.18-1, automatic), libccid:amd64
(1.4.34-1, automatic), lockfile-progs:amd64 (0.1.18,
automatic), apt-config-icons:amd64 (0.14.2-1, automatic),
libtype-tiny-perl:amd64 (1.012001-2, automatic), libndp0:amd64
(1.6-1+b1, automatic), libsub-handlesvia-perl:amd64 (0.016-1,
automatic), gnome-settings-daemon:amd64 (3.38.1-3, automatic),
libteam5:amd64 (1.31-1, automatic), policykit-1-gnome:amd64
(0.105-7, automatic), rygel-ruih:amd64 (0.40.0-1, automatic),
libnma0:amd64 (1.8.30-1, automatic), libteamdctl0:amd64
(1.31-1, automatic), libteam-utils:amd64 (1.31-1, automatic),
libgupnp-av-1.0-2:amd64 (0.12.11-2, automatic),
libffmpegthumbnailer4v5:amd64 (2.1.1-0.2+b1, automatic),
tumbler-plugins-extra:amd64 (4.16.0-1, automatic),
network-manager:amd64 (1.30.0-1, automatic), libopenraw7:amd64
(0.1.2-0.2, automatic), software-properties-gtk:amd64
(0.96.20.2-2.1, automatic), vpnc-scripts:amd64
(0.1~git20200930-1, automatic), pcscd:amd64 (1.9.1-1,
automatic), libpkcs11-helper1:amd64 (1.27-1, automatic),
libqb100:amd64 (2.0.3-1, automatic), snapd:amd64 (2.49-1,
automatic), libpackagekit-glib2-18:amd64 (1.2.2-2, automatic),
rygel:amd64 (0.40.0-1, automatic), libdata-perl-perl:amd64
(0.002011-1, automatic), libmoox-handlesvia-perl:amd64
(0.001009-1, automatic), libtumbler-1-0:amd64 (4.16.0-1,
automatic), pipewire-bin:amd64 (0.3.19-4, automatic),
gnome-control-center-data:amd64 (1:3.38.4-1, automatic),
mutter:amd64 (3.38.3-5), msva-perl:amd64 (0.9.2-1.1,
automatic), liblinux-inotify2-perl:amd64 (1:2.2-2+b1,
automatic), network-manager-pptp:amd64 (1.2.8-3+b2,
automatic), libiw30:amd64 (30~pre9-13.1, automatic),
libnss-resolve:amd64 (247.3-3, automatic),
gir1.2-malcontent-0:amd64 (0.10.0-2, automatic),
python3-protobuf:amd64 (3.12.4-1, automatic),
libhttp-server-simple-perl:amd64 (0.52-1.1, automatic),
openvpn-systemd-resolved:amd64 (1.3.0-3.1, automatic),
openssh-sftp-server:amd64 (1:8.4p1-5, automatic),
librygel-db-2.6-2:amd64 (0.40.0-1, automatic),
libspa-0.2-modules:amd64 (0.3.19-4, automatic),
openconnect:amd64 (8.10-2+b1, automatic),
accountsservice:amd64 (0.6.55-3, automatic),
libgepub-0.6-0:amd64 (0.6.0-2, automatic),
gnome-control-center:amd64 (1:3.38.4-1, automatic),
network-manager-vpnc:amd64 (1.2.6-3, automatic),
libxml-simpleobject-libxml-perl:amd64 (0.53-3, automatic),
gnupg-agent:amd64 (2.2.27-1, automatic), libnl-nf-3-200:amd64
(3.4.0-1+b1, automatic), libconfig-general-perl:amd64 (2.63-1,
automatic), librygel-renderer-2.6-2:amd64 (0.40.0-1,
automatic), colord-data:amd64 (1.4.5-3, automatic),
libflatpak0:amd64 (1.10.2-1, automatic), iw:amd64 (5.9-3,
automatic), crda:amd64 (4.14+git20191112.9856751-1,
automatic), libcheese8:amd64 (3.38.0-3, automatic),
libgnome-bluetooth13:amd64 (3.34.3-2, automatic),
gnome-software-plugin-flatpak:amd64 (3.38.1-1, automatic),
opensc:amd64 (0.21.0-1, automatic), libnet-xmpp-perl:amd64
(1.05-1.1, automatic), sendxmpp:amd64 (1.24-3, automatic),
libumockdev0:amd64 (0.15.4-1, automatic),
libpipewire-0.3-modules:amd64 (0.3.19-4, automatic),
python3-axolotl:amd64 (0.2.3-4, automatic), flatpak:amd64
(1.10.2-1, automatic), realmd:amd64 (0.16.3-3, automatic),
libmediaart-2.0-0:amd64 (1.9.4-3, automatic),
liblockfile1:amd64 (1.17-1+b1, automatic), rygel-tracker:amd64
(0.40.0-1, automatic), opensc-pkcs11:amd64 (0.21.0-1,
automatic), python3-asn1crypto:amd64 (1.4.0-1, automatic),
cheese-common:amd64 (3.38.0-3, automatic),
libaccountsservice0:amd64 (0.6.55-3, automatic), libnm0:amd64
(1.30.0-1, automatic), libopenrawgnome7:amd64 (0.1.2-0.2,
automatic), libgeoclue-2-0:amd64 (2.5.7-2, automatic),
python3-libxml2:amd64 (2.9.10+dfsg-6.3+b1, automatic),
libopenconnect5:amd64 (8.10-2+b1, automatic),
libclutter-gst-3.0-0:amd64 (3.0.27-2, automatic),
xdg-desktop-portal:amd64 (1.8.1-1, automatic),
liblwp-protocol-socks-perl:amd64 (1.7-1.1, automatic),
libcolord-gtk1:amd64 (0.1.26-2, automatic),
mobile-broadband-provider-info:amd64 (20201225-1, automatic),
libpipewire-0.3-0:amd64 (0.3.19-4, automatic)

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#234841

On Wed 05 May 2021 at 03:11:53 (+0200), Emanuel Berg wrote:
> Kushal Kumaran wrote:
> 
> > The manpage at
> > https://manpages.debian.org/buster/iwatch/iwatch.1.en.html
> > shows log output similar to what you see. Check your iwatch
> > configuration and see what it is doing.
> 
> Thanks, but I've never heard of iwatch, so I haven't mucked
> around with its config file. But OK, here it is

[ … configuration … ]

> Does that say anything to you?

It looks reasonable for determining whether your system files are
being interfered with. But you just showed one example from the
log, which was for the /etc/.pwd.lock lockfile. I assume you don't
have 2757 of these but, rather, the names of an assortment of files.

So—you're interfering with the system, by installing, removing and
reconfiguring software; people are changing their passwords, and
so on.

You might be able to correlate the timestamps of some of the changes
being made with those in logs like /var/log/apt/history*, which
shows software upgrades.

/etc/.pwd.lock is probably not a good example, as it's opened for
writing but not written to. On my system, it's the 3rd-oldest
file modification in /etc (after /etc/{shells,environment} and
before /etc/{adduser.conf,machine-id}).

BTW,

  $ aptitude why iwatch

or

  $ zgrep -B1 iwatch /var/log/apt/history.log*

might help determine why you installed iwatch.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#234842

David Wright wrote:

> might help determine why you installed iwatch.

Oh, so I did?

Well then, I'll just remove it!

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#234844

On Wed 05 May 2021 at 04:39:21 (+0200), Emanuel Berg wrote:
> David Wright wrote:
> 
> > might help determine why you installed iwatch.
> 
> Oh, so I did?
> 
> Well then, I'll just remove it!

Myself, I find inotify-tools more useful: I use inotifywait in a loop,
waiting for a browser to close files in its cache. I then examine
their filetype and copy the ones I want, giving them sensible
(timestamp) names. Very useful for capturing (typically, live) video.

But I can see the usefulness of iwatch if you're maintaining a
website or a server farm, as in their examples. (My random collection
of PCs only constitutes a smallholding.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#234845

David Wright wrote:

> Myself, I find inotify-tools more useful: I use inotifywait
> in a loop, waiting for a browser to close files in its
> cache. I then examine their filetype and copy the ones
> I want, giving them sensible (timestamp) names. Very useful
> for capturing (typically, live) video.
>
> But I can see the usefulness of iwatch if you're maintaining
> a website or a server farm, as in their examples. (My random
> collection of PCs only constitutes a smallholding.)

Yeah, I'm sure it is a good tool when it works but here
something has gone haywire so better remove it...

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#234861

On Tue, May 04, 2021 at 09:32:49PM -0500, David Wright wrote:
> It looks reasonable for determining whether your system files are
> being interfered with. But you just showed one example from the
> log, which was for the /etc/.pwd.lock lockfile. I assume you don't
> have 2757 of these but, rather, the names of an assortment of files.

That's an interesting interpretation.  If that's actually *true*, I
wish the OP had made that more clear.  I interpreted it as literally
being thousands of instances of the *same* file, the one shown in the
Subject: header and in the original message body.

(In which case, removing iwatch will certainly stop the logging, but
it won't stop whoever is locking and unlocking your passwd/shadow
files thousands of times, which is something I might care enough to
investigate -- and is a great reason for installing iwatch, to look for
such a thing.)

(Also I'd never heard of "monkeysphere" before and didn't even know
that openssh-client suggested it.  So it's been an educational thread.)

[toc] | [prev] | [next] | [standalone]

#234869

Greg Wooledge wrote:

> I interpreted it as literally being thousands of instances
> of the *same* file, the one shown in the Subject: header and
> in the original message body.

They were all from iwatch, but they were so many I don't know
if they were exactly the same, and now I don't get any (mails)
anymore. Good :)

> (Also I'd never heard of "monkeysphere" before and didn't
> even know that openssh-client suggested it. So it's been an
> educational thread.)

Yes, thanks everyone :)

I learned something as well, how to delete mails. First see
how many mails there are, say there are 756, then type t 1-756
RET and then hold down q :)

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#234976

On Wed, May 05, 2021 at 03:51:16PM +0200, Emanuel Berg wrote:
>I learned something as well, how to delete mails. First see
>how many mails there are, say there are 756, then type t 1-756
>RET and then hold down q :)

That's a slow way. "T iwatch ; d" or "T ~b iwatch ; d" would be faster
(using ; bound to tag-prefix: apply next function to tagged messages)


-- 
Please do not CC me, I am subscribed to the list.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#235009

Jonathan Dowland wrote:

> On Wed, May 05, 2021 at 03:51:16PM +0200, Emanuel Berg wrote:
>
>> I learned something as well, how to delete mails. First see
>> how many mails there are, say there are 756, then type
>> t 1-756 RET and then hold down q :)
>
> That's a slow way. "T iwatch ; d" or "T ~b iwatch ; d" would
> be faster (using ; bound to tag-prefix: apply next function
> to tagged messages)

d * even faster perhaps...

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#234881

On Wed 05 May 2021 at 07:26:34 (-0400), Greg Wooledge wrote:
> On Tue, May 04, 2021 at 09:32:49PM -0500, David Wright wrote:
> > It looks reasonable for determining whether your system files are
> > being interfered with. But you just showed one example from the
> > log, which was for the /etc/.pwd.lock lockfile. I assume you don't
> > have 2757 of these but, rather, the names of an assortment of files.
> 
> That's an interesting interpretation.  If that's actually *true*, I
> wish the OP had made that more clear.  I interpreted it as literally
> being thousands of instances of the *same* file, the one shown in the
> Subject: header and in the original message body.

Yes, it was an assumption, and perhaps now we shall never know.
(Sampling the emails didn't appeasr to be an option.)
We also were not told whether 2757 notifications came in over
a week, a month, a year, or since openssh-client was installed,
whenever that was (possibly at installation).

  $ zgrep ':[0-9][0-9] configure ' /var/log/dpkg.log* | sort -k 4 | less
run on this system, which has just passed its first birthday¹, shows
2788 lines, and each must represent a number of modifications to
the directories given earlier (/etc, /[s]bin, /lib). So 2757 looks
small in that context.

OTOH perhaps monkeysphere has some reason to lock /etc/passwd et al
during operation. Running strings on its binaries might throw up
some 'pwd.lock' matches. Or one could inotifywatch the program to
see how often it is run (unless it's a daemon). Just thinking aloud.

> (In which case, removing iwatch will certainly stop the logging, but
> it won't stop whoever is locking and unlocking your passwd/shadow
> files thousands of times, which is something I might care enough to
> investigate -- and is a great reason for installing iwatch, to look for
> such a thing.)
> 
> (Also I'd never heard of "monkeysphere" before and didn't even know
> that openssh-client suggested it.  So it's been an educational thread.)

One thing I didn't learn is why .pwd.lock is in /etc/ rather than,
say, /run/lock/. Perhaps related, why are there dotfiles in /etc/
anyway. (.git/, .java/, .etckeeper, .gitignore are the others.)
What are they hiding from?

¹ alternatives, apt, and dpkg have 5yr log rotation, exim has 10.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#234882

David Wright wrote:

> Yes, it was an assumption, and perhaps now we shall never
> know. (Sampling the emails didn't appeasr to be an option.)
> We also were not told whether 2757 notifications came in
> over a week, a month, a year, or since openssh-client was
> installed, whenever that was (possibly at installation).

Oh, no, I removed mails all the time, they came at least every
10 minutes or so is what I would approximate from the holster.

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#234883

On Wed, May 05, 2021 at 10:36:53AM -0500, David Wright wrote:
> OTOH perhaps monkeysphere has some reason to lock /etc/passwd et al
> during operation. Running strings on its binaries might throw up
> some 'pwd.lock' matches. Or one could inotifywatch the program to
> see how often it is run (unless it's a daemon). Just thinking aloud.

I actually looked for that filename in "strings /usr/bin/sudo" and
"strings /usr/sbin/vipw" before Google told me that it's used by those
libc functions (lckpwdf(3) and its buddy ulckpwdf(3)).

It's a bit odd that the man page doesn't contain the filename.  Usually
you'd expect it to.

> One thing I didn't learn is why .pwd.lock is in /etc/ rather than,
> say, /run/lock/. Perhaps related, why are there dotfiles in /etc/
> anyway. (.git/, .java/, .etckeeper, .gitignore are the others.)
> What are they hiding from?

This predates /run by a long time.

Also, presumably, it wants to be in /etc because that's where the file
that it's paired with lives.  Dot-lock files are usually in the same
location as the files they represent.

Why the dot?  So that it doesn't show up in a casual "ls" and cause a
bunch of n00b questions, obviously.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web