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 2 of 2 — ← Prev page 1 [2]

#234887

Greg Wooledge wrote:

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

Yes, because you learn about dotfiles - is it the first or
second week of using a Unix system?

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

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

#234900

On Wed 05 May 2021 at 12:01:07 (-0400), Greg Wooledge wrote:
> 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.

Yes—though its name, in fact, ensures that it never lists next to any
of the files that it might be assumed to lock.

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

Yes, I can understand that for the users' home directories; they don't
want listings of their own files to be interspersed with configuration
files. And many of the latter files will be read and written on behalf
of the user rather than by themselves, so there's little need for them
to see them all the time.

But /etc isn't anybody's home directory: it's configuration information
for the whole system. So there's no need to dot any of the files and
directories in order to either inform the sysadmin that these are
configuration files, or to hide them. Anyway, that was my (related) point.

Cheers,
David.

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

#234898

On Wed, 5 May 2021 10:36:53 -0500
David Wright <deblis@lionunicorn.co.uk> wrote:

> [W]hy are there dotfiles in /etc/ anyway.
> (.git/, .java/, .etckeeper, .gitignore are the others.) What are they
> hiding from?

Indeed. And shouldn't one be backing them up?

I see that amanda has been backing them up and that "add *" in
amrecover does add them to the extract list (phew!). Would other backup
tools catch dotfiles?

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#234915

On Wed, 5 May 2021 David Wright wrote:
[dd]
>
> 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?
[dd]

I would assume that they are "hidden" because they are merely
peripheral or auxiliary to the *purpose* of the directory containing
them.

We tend to group files into directories devoted to one function or
another. This certainly seems to be the unstated premise of hier(7),
for example.

So home directories hold a user's content. Per-user configuration
falls outside that canonical function, hence the ~/.dotfile convention
in home directories.

Likewise, I assume that files under /etc are text files that determine
system configuration, and that if system configuration is something I
care about, then I ought to at least gain a passing familiarity with
each such file under /etc, ideally (eventually) become familiar with
its content and function, and generally consider myself responsible
for the conseqences of that content, take responsiblity for reviewing
and editing it, etc.

To that end, I can occasionally do something like

  $ ls -Rp | less

and make a point of examining the first couple of things that look
unfamiliar.

This misses out dotfiles. But with a few exceptions --which seem to
prove the rule after all-- this omission serves my purposes just
fine. That is, when I understand the purpose of the file hierarchy
then I know where to look to find what I want, and I'm spared the
trouble of ignoring certain files whose presence is
helpful-yet-peripheral to the purpose of a given directory.

So when I look for what I'm missing out on, and do...

  $ shopt -s globstar
  $ ls /etc/**/.[^.]*

...then I find

  * /etc/.pwd.lock, clearly an exception to the /etc profile above
  * various ".placeholder" files, also clear exceptions
  * model (eponymous) home directory config files under /etc/skel
  * some ".depends.*" files in /etc/init.d/ which are not init scripts

I don't have under /etc any of .git/, .gitignore, .etckeeper, .java/.
But don't they contain mere meta-info, relative to the primary purpose
of the directory containing them? (I don't know a thing about .java/
btw, so am curious.)

If I put say /etc/default/ under revision control, I would not want
new meta-files appearing whenever I did "ls /etc/default".

-- 
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower

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

#234918 — OT: dotfile generalities (was Re: repeated system mail, /etc/.pwd.lock ?)

On Thu, 6 May 2021 davidson wrote:
[dd]
> To that end, I can occasionally do something like
>
> $ ls -Rp | less
>
> and make a point of examining the first couple of things that look
> unfamiliar.
>
> This misses out dotfiles.
[dd]
> So when I look for what I'm missing out on, and do...
>
> $ shopt -s globstar
> $ ls /etc/**/.[^.]*

It now occurs to me that this still omits files like /etc/.a and
/etc/..metadotfile

Instead,

  $ ls /etc/**/.{.?,[^.]}*

does what I intend, which is to display all dotfiles under /etc. Seems
unduly complicated if you ask me, but it is what it is.

I can feel it coming on: Someone is going to tell me to just use find.

Talk about unduly complicated! And I don't want to.

>
> ...then I find
>
> * /etc/.pwd.lock, clearly an exception to the /etc profile above
> * various ".placeholder" files, also clear exceptions
> * model (eponymous) home directory config files under /etc/skel
> * some ".depends.*" files in /etc/init.d/ which are not init scripts
[dd]

-- 
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower

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

#234920 — Re: OT: dotfile generalities (was Re: repeated system mail, /etc/.pwd.lock ?)

On Thu, May 06, 2021 at 02:37:17PM +0000, davidson wrote:
> > $ shopt -s globstar
> > $ ls /etc/**/.[^.]*
> 
> It now occurs to me that this still omits files like /etc/.a and
> /etc/..metadotfile

It doesn't omit .a .  The * is allowed to match the empty string.

> Instead,
> 
>  $ ls /etc/**/.{.?,[^.]}*
> 
> does what I intend, which is to display all dotfiles under /etc. Seems
> unduly complicated if you ask me, but it is what it is.

find /etc -type f -name '.*'

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

#234957 — Re: OT: dotfile generalities (was Re: repeated system mail, /etc/.pwd.lock ?)

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

On Thu 06 May 2021 at 10:46:03 (-0400), Greg Wooledge wrote:
> On Thu, May 06, 2021 at 02:37:17PM +0000, davidson wrote:
> > > $ shopt -s globstar
> > > $ ls /etc/**/.[^.]*
> > 
> > It now occurs to me that this still omits files like /etc/.a and
> > /etc/..metadotfile
> 
> It doesn't omit .a .  The * is allowed to match the empty string.
> 
> > Instead,
> > 
> >  $ ls /etc/**/.{.?,[^.]}*
> > 
> > does what I intend, which is to display all dotfiles under /etc. Seems
> > unduly complicated if you ask me, but it is what it is.
> 
> find /etc -type f -name '.*'

Well, here are the files on my system:

#  find /etc -type f -name '.*' -ls | sort -k 11
 -rwx------ 84357 May  6 08:25 /etc/.etckeeper
 -rw-------   932 Apr  3  2020 /etc/.gitignore
 -rw-r--r--     0 Apr  3  2020 /etc/.java/.systemPrefs/.system.lock
 -rw-r--r--     0 Apr  3  2020 /etc/.java/.systemPrefs/.systemRootModFile
 -rw-------     0 Apr  3  2020 /etc/.pwd.lock
 -rw-r--r--   102 Jun 23  2019 /etc/cron.d/.placeholder
 -rw-r--r--   102 Jun 23  2019 /etc/cron.daily/.placeholder
 -rw-r--r--   102 Jun 23  2019 /etc/cron.hourly/.placeholder
 -rw-r--r--   102 Jun 23  2019 /etc/cron.monthly/.placeholder
 -rw-r--r--   102 Jun 23  2019 /etc/cron.weekly/.placeholder
 -rw-r--r--     0 Dec 19  2018 /etc/sensors.d/.placeholder
 -rw-r--r--   220 Apr 17  2019 /etc/skel/.bash_logout
 -rw-r--r--  3526 Apr 17  2019 /etc/skel/.bashrc
 -rw-r--r--   807 Apr 17  2019 /etc/skel/.profile
# 

(I removed the node#, usage, #links and ownership for brevity.)

I have no argument with /etc/skel/ and the placeholders, obviously.
/etc/.etckeeper is a script for creating directories and resetting
ownerships/permissions in /etc/, and /etc/.gitignore is a list of
filename patterns that etckeeper is configured not to track.

Turning to the dot-directories with:

  # ls -GlgAR /etc/\.[^\.]*/   (pruned and attached)

/etc/.git/ certainly contains configuration files as well as the
repository itself. I know nothing about java, and how /etc/.java
relates to /etc/java/.

Most of this stuff is protected from reading, but I don't see the
point in "hiding" them with dots.

Cheers,
David.

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

#234960 — Re: OT: dotfile generalities (was Re: repeated system mail, /etc/.pwd.lock ?)

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

On Thu, May 06, 2021 at 11:21:14PM -0500, David Wright wrote:

[...]

> Well, here are the files on my system:
> 
> #  find /etc -type f -name '.*' -ls | sort -k 11
>  -rwx------ 84357 May  6 08:25 /etc/.etckeeper
>  -rw-------   932 Apr  3  2020 /etc/.gitignore
>  -rw-r--r--     0 Apr  3  2020 /etc/.java/.systemPrefs/.system.lock
>  -rw-r--r--     0 Apr  3  2020 /etc/.java/.systemPrefs/.systemRootModFile
>  -rw-------     0 Apr  3  2020 /etc/.pwd.lock
>  -rw-r--r--   102 Jun 23  2019 /etc/cron.d/.placeholder
>  -rw-r--r--   102 Jun 23  2019 /etc/cron.daily/.placeholder
>  -rw-r--r--   102 Jun 23  2019 /etc/cron.hourly/.placeholder
>  -rw-r--r--   102 Jun 23  2019 /etc/cron.monthly/.placeholder
>  -rw-r--r--   102 Jun 23  2019 /etc/cron.weekly/.placeholder
>  -rw-r--r--     0 Dec 19  2018 /etc/sensors.d/.placeholder
>  -rw-r--r--   220 Apr 17  2019 /etc/skel/.bash_logout
>  -rw-r--r--  3526 Apr 17  2019 /etc/skel/.bashrc
>  -rw-r--r--   807 Apr 17  2019 /etc/skel/.profile
> # 

Nice stats :)

So those are 14 things.

 - 8 of them I'd attribute to etckeeper (the .placeholder ones,
   because git never grokked empty directories)
 - 3 are just part of a directory template (skel)
 - 2 (well, it's actuall a fractal, as usual in that culture)
   are "some Java stuff"
 - 1 I don't understand (who is .pwd.lock and what is she
   doing in my /etc? [1]).

Cheers

[1] https://www.reddit.com/r/shittyaskreddit/comments/7mq5f9/who_is_general_failure_and_why_is_he_reading_my/

 - t

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

#234961 — Re: OT: dotfile generalities (was Re: repeated system mail, /etc/.pwd.lock ?)

On Fri, 2021-05-07 at 09:39 +0200, tomas@tuxteam.de wrote:
>  - 1 I don't understand (who is .pwd.lock and what is she
>    doing in my /etc? [1]).

I thought that was explained on this list a few days ago (and 17 years
ago! [2]). The file is used by lckpwdf() function [3][4] which is used
to serialise modification to /etc/passed and friends.

> [1] https://www.reddit.com/r/shittyaskreddit/comments/7mq5f9/who_is_general_failure_and_why_is_he_reading_my/

[2] https://lists.debian.org/debian-user/2005/07/msg02949.html
[3] https://linux.die.net/man/3/lckpwdf
[4] http://sourceware.org/git/?p=glibc.git;a=blob;f=shadow/lckpwdf.c;hb=284128f68f27567f9cad0078c97d7d807475e0a7


-- 
Tixy

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

#234962 — Re: OT: dotfile generalities (was Re: repeated system mail, /etc/.pwd.lock ?)

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

On Fri, May 07, 2021 at 09:46:53AM +0100, Tixy wrote:
> On Fri, 2021-05-07 at 09:39 +0200, tomas@tuxteam.de wrote:
> >  - 1 I don't understand (who is .pwd.lock [...])

> I thought that was explained on this list a few days ago [...]

Oh, thanks. Must have missed that part :)

Cheers
 - t

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

#235010

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.
> 
> (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.)

FYI:

I installed iwatch, and that immediately generated two messages from
/etc/.etckeeper. Then I upgraded:

  apt apt-doc apt-utils bind9-host curl dnsutils exim4 exim4-base exim4-config exim4-daemon-light
  firefox-esr firefox-esr-l10n-en-gb gstreamer1.0-gl gstreamer1.0-libav gstreamer1.0-plugins-bad
  gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-pulseaudio gstreamer1.0-x
  libapt-inst2.0 libapt-pkg5.0 libbind9-161 libcurl3-gnutls libcurl4 libdns-export1104 libdns1104
  libgstreamer-gl1.0-0 libgstreamer-plugins-bad1.0-0 libgstreamer-plugins-base1.0-0 libirs161
  libisc-export1100 libisc1100 libisccc161 libisccfg163 libjs-underscore libldb1 liblwres161
  libopenjp2-7 openjdk-11-jre openjdk-11-jre-headless wpasupplicant xserver-common
  xserver-xorg-core xserver-xorg-legacy
44 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

and got 387 more messages.

I then added one new user, which generated 97 more, where
/etc/.pwd.lock was the subject of four of them.

Purging iwatch then generated a final three.

So the OP's 2757 is no surprise with the default configuration.

Cheers,
David.

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

#235027

David Wright wrote:

> FYI:
>
> I installed iwatch, and that immediately generated two messages from
> /etc/.etckeeper. Then I upgraded:
>
>   apt apt-doc apt-utils bind9-host curl dnsutils exim4
> exim4-base exim4-config exim4-daemon-light
>   firefox-esr firefox-esr-l10n-en-gb gstreamer1.0-gl
> gstreamer1.0-libav gstreamer1.0-plugins-bad
>   gstreamer1.0-plugins-base gstreamer1.0-plugins-good
> gstreamer1.0-pulseaudio gstreamer1.0-x
>   libapt-inst2.0 libapt-pkg5.0 libbind9-161 libcurl3-gnutls
> libcurl4 libdns-export1104 libdns1104
>   libgstreamer-gl1.0-0 libgstreamer-plugins-bad1.0-0
> libgstreamer-plugins-base1.0-0 libirs161
>   libisc-export1100 libisc1100 libisccc161 libisccfg163
> libjs-underscore libldb1 liblwres161
>   libopenjp2-7 openjdk-11-jre openjdk-11-jre-headless
> wpasupplicant xserver-common
>   xserver-xorg-core xserver-xorg-legacy
> 44 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>
> and got 387 more messages.
>
> I then added one new user, which generated 97 more, where
> /etc/.pwd.lock was the subject of four of them.
>
> Purging iwatch then generated a final three.
>
> So the OP's 2757 is no surprise with the
> default configuration.

Really, I was 100% it was something _I_ did...

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web