From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A84EF139335 for ; Mon, 28 Jun 2021 03:36:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AAE92E086E; Mon, 28 Jun 2021 03:35:51 +0000 (UTC) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BF005E0844 for ; Mon, 28 Jun 2021 03:35:50 +0000 (UTC) Received: by mail-oi1-x22c.google.com with SMTP id w127so20390599oig.12 for ; Sun, 27 Jun 2021 20:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SCl4EMt4Qq0xnD+Brewnmy26UGrVokNBdBpDT4+OWJo=; b=bxT8pm/Nfmt9rUOj0WISEC90PsrDBpGgS9DdqlP99cjPMqxTpZ//u4fRJj5epClKix 9JSrD9UmAOq6QfsdMCEomEGKGsc9FX6EhUmR1UF+8ZZC/wHphKcTYNrkmkMzlfRM0oQs PY5Ff7CXd7rTlpmAu/bREQVxOe6hIOeWkrcMDUyjOEzhoodjmqntGA7+x9BxkJxjqtPA Cwj03wLQgXKn6WUnV4DKmSL+PX2w4sUWFFtHmpHnZhmH3yCSL/EuIMJXTbhbSi0i29lE 18y0LbmWCq8Coys3DUTxZmwaR5hKzf7m/i7PfJXqp9cjOdIPVKnRsN+sY9Mv3PcmUOxQ htkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=SCl4EMt4Qq0xnD+Brewnmy26UGrVokNBdBpDT4+OWJo=; b=MjGVqQedo6qpvKqOeQfkRwsOUGIvXjF07w/9fusaRXlFgTc0UhIEFNylZ+QweF5CTt ao3tovXE22eME8R2lfOuKu4OUtSkfVUwE2Pz1xjBUm/1dyBvTnV0U4lG56JTtexInPn3 iSHqzB+m6M3U0H+FmQp0oJRFs+jxOR8ZGUCQnK4jw3hPJzViBYksxqhlGJTf85wuOO8Q Cysd4KvbZJOkdIpDmIrmlCxa2YlqnW9ktFkp20hzI3Eov4/w2u7Ukqg+Dd4NW82UjVe6 WugmDHk5Xwu4YTSRbUr6gvp+8/TAvmgx/oB4EURjUF5UwLq1hfAmZNSqZ6nFAOond/LZ aoSw== X-Gm-Message-State: AOAM533ltOOcoKzF0Oqetp3PN8tPYo5UanU9NngtGgfzxizLPdI3AQ9V 06Oh94HPplNJJ0n62S8MjHE= X-Google-Smtp-Source: ABdhPJxUemtT1X8gjwBuuCBegpLUMPJAGGLFoPW351mXNBUEl4rnWAoxob8yCojYiRkJrqgI4z4B+w== X-Received: by 2002:aca:5889:: with SMTP id m131mr19087094oib.140.1624851349883; Sun, 27 Jun 2021 20:35:49 -0700 (PDT) Received: from [192.168.0.100] (adsl-074-188-244-166.sip.asm.bellsouth.net. [74.188.244.166]) by smtp.gmail.com with ESMTPSA id p5sm2917499oip.35.2021.06.27.20.35.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Jun 2021 20:35:49 -0700 (PDT) Subject: Re: [gentoo-user] cryptsetup close and device in use when it is not From: Dale To: gentoo-user@lists.gentoo.org References: <70a1b488-c49e-6a94-a9a9-37eeb2ff4399@gmail.com> <9c9d5923-dccb-34d5-0f3b-16e07f337009@users.sourceforge.net> <649753f7-5dcd-1842-875d-d637ef754b9f@gmail.com> <3923b557-9d65-825b-e0fd-b1977c8d70c1@gmail.com> <7c279941-291a-5078-a83f-601ff58a6008@gmail.com> <9946c2eb-bb5c-a9c0-ced9-1ac269cd69a0@gmail.com> Openpgp: preference=signencrypt Autocrypt: addr=rdalek1967@gmail.com; prefer-encrypt=mutual; keydata= mQINBFxc7MgBEAC+zrgEdqJJiDe/UDAB+ScmferXWfJTVjbVT2T4DQ7jiLrgP9aNUo1HioNF mrU3JPOCR32gvZyTbY1+niO5+VSo/+pSqQ785h6ZDj1klMkrg6tEzGnf2MNBpBj4houZwxQ+ WDKKTg2M9F+lv8wTIdR/JQn+hSviktLMtrghQlyLhpapsLXWLA6gMFebpQYwxUwemvan8ddX lQvJe9FGyFYvBi0dp1gl10F2O+DVZJxvX8xkX+yImVlhVJiC31gXHRcj+Qlo7gprlU7TIieF Uow6/ZvYKJ26pztVdFCg5w0rMJkF/x8Zd4A6wnuptiAPmWaQ1+YKgYDonbDUgwqFSx5/lN5z DGZ4LlioxeUTTPVvZsqBIeDz6jNFA583OYbo1/S26dqrvTFf2DKlsvoDpVfAhNlwJPjoixs0 X3FNqPv+M10n4kq5Iz7Q9E3O4s/nfFIYGocEslVka7zZPkXSaHbsn+KJlY8XV6qxtCEdh0/V XX1+1aU2J74M0JikWhpwxTZ1dP5aOyWSPPEgFFIRW6xwwC02SoRH9a7mggfGYp/YjPlONNaT SCL8sgRfvmq3D0XTbLyTjSbExxkfKDmbePQagawDE3TlI/oivHf1JaAcbwMb3LZuU4TGcOIl 5D+x7q0MUIeCop0ZFOwAnqW3AVVNvsBkv2KN+IHJryWAf0/iMQARAQABtBtEYWxlIDxyZGFs ZWsxOTY3QGdtYWlsLmNvbT6JAk4EEwEIADgWIQTZ7suruPBaS60bCYXvEM/XWu+ZnAUCXFzs yAIbIwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRDvEM/XWu+ZnN+7D/4/1dNG4aCz0+v+ 0dcjV5tY1feYEWCdHKyDzxWBxlCpd/0NPRQeNY4VMjbCl/sq7GkXi/c2SbfWDQ5BQRkkExG1 pSwuXSIehGok/4fpTi3HDAguRvzdCqlKPt7me05FyiC/WnpY5GOlJ3ruGw2qABv/RmV2q5b/ tkq7h1y1f16DTNr3/nsj8HzHcrHdXdL4kaYChSOe/dbQR9Stqak7eMyR+iwvrJMNF/CGl70P 2x5ybsXMDzRVOqNcpa5ZdhEMTVh6+vC1SOmm1BFMF8XCqBEvBbcHWDQmGYTdNCsS/ADm8CBl gvjJgLdIsAzoMu4WHQDFnzXAoArqFWgAf53isOS4AWrv29tF9b8Aa1vb7h5JEa+ArcMsA6Gl X38+GY6WXXaxKI9n3PTCWu9tPGnRh7mABjnwEosDDqmzw8aTAYECb3avDuGY2rmcjgh4H6RE w08d63j1T4d5J9wlm4TGtW/VHgbUFkATEdH3Acl/EjFiyqTiX7p8kU6Reu5enIkogA93xoQh Rmy7ZiST/5LN+ZkaOdyjIw0L+5KalslN9SKt809YxgJ6kPo657LNTFPiFvFA46/SEWcBYrzq Xk0wEW0gBRWf+BqN0qRhU0/EQ+QfRdLLFg2xtUePwlheYLXxfyDLrdCCOLWYpkzbjCZHLS4u 69smbvR9S9KBDNzJybxEWrkCDQRcXOzIARAA5IGRWTqaM44IJgBYghZg2fGj0Am7KWPhE7V7 T/EEe7vVSUEFqHtlHzI4ZK6Q0AZ9uAEjE8IJIQ7KoTjzNqAtabP0vp3s0szgtJlsZ+8vGKlQ my7fvzSrdoQL0Xn7CEwJYFXJ1EMUcYIQeoHG1cUAaXx73k9BFbjwjnUeMrqlV/ZovQlg7duW nESfQ7HZu5NrtYyY3jPMUouxiO9WQPh+IHxZbt1absF2VcvRAymD32RxGvMPbw6ChMRD/p9O 4PH7M5rXaxr78NXQX9E48vrI00f1cYb9NSN1HnSV8cW3jKObVjdBk6jPQwrMvdpgdQhUB9aZ HS/9mC9mmAgiXKyCpzXe7FPB6QznSfn4GIaC/luy1e6SLUkJhRK/niB+gq+Mfxg2zXNuDUTI cMGmpDCp3kgUoorkaltk8RW09io95BkXrGhcDNuSGZfAParBc7RXyYpbIcax8St7tEAd2oFh 4seYOPUlzuhGrPpqR/91wrFc4E1260GKauSr4UhMJv6tygBwyC0mmBMKi+ZXw6ZdZxA5fg7y 35P3TILjznCXXTDgRHq9A3NknKRMcgFacX6eIhANkMFo6oJVjuEgy1dvu1wFfDq7c+i8GAHu L4pYzyXYu6PporlNNU0xSwdVgzM/uuK0lt+UxCimgC+YR3IezgDcbfudb7h9dGIwL+bbPL0A EQEAAYkCNgQYAQgAIBYhBNnuy6u48FpLrRsJhe8Qz9da75mcBQJcXOzIAhsMAAoJEO8Qz9da 75mcXZ4P/1YXgWDZek7mhzrf6uaQzMxa92P89HeWz4PlgB/32symeEFAV04WazzBZffI8AYY rGA1Xmu/2VaB9+FOODyKhUWBc2UL0NRWBk6POwboyTdKlclmpixaN9zLcBt0YLejoRfN1B/5 aQf9/lUDZMnAiCyz0FgeqEMUshldmwWC35RqnjrCbbuk2vIqSH6BLDIXU6jQrLHE1DF0ai41 wLtQFAFXPhn45n0ZwYhVs4Z32z4sjXrIvgBgCaXa4HM+L1Klne0KiNM8ReFTTpTE0SgyDOSZ O3MOa2n77i6JbVtsbiFYnNeP3J9S/l3jevGpZEtNQOKrIm1MW8jGuHWtsDeMkT/mCcSodlkt PxIo+mMK9GpGvG2hW80LiohqNfUbNwAmr3blOYY4URPXPRnEnPs4pmTmL5owjw2dkg145i9I D42Tq+XZ6YtWt3SGzGbAYow6XwTwZ5NFAzV9UQuCGrDw4KWan6O6Z+VIYWsn0UMZlu1Obxna aocofkaUCbISK26kImuD1aA8juSHC18Qv1xUage6/UakbSxyDtACqt6hOVFKX3IA59ApdNRT +2x3iCmlvF9MJsGgFq6IpqL+Fk7iWV8Kjbz0wQOId6N9+JdQh3LrLaS7a1PowUm1z9DK5/O0 Yg+gpDnEOOFI7WM5u7a7FSM2Z/LXGVwel/0eWvLk9tN6 Message-ID: <6ecbf2d6-2c6f-3f66-5eee-f4766d5e5254@gmail.com> Date: Sun, 27 Jun 2021 22:35:47 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.8 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: <9946c2eb-bb5c-a9c0-ced9-1ac269cd69a0@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: ca5472fa-ac59-4a4d-9482-a93955f51c81 X-Archives-Hash: 784154458cbc428c781f76ed6588097f Dale wrote: > Dale wrote: >> Dale wrote: >>> Dale wrote: >>>> Dale wrote: >>>>> Jack wrote: >>>>>> Is it possible it was still syncing cache out to the physical drive?  >>>>>> I wonder if iotop would show any activity for that drive if that's the >>>>>> case? >>>>>> >>>>>> Jack >>>>>> >>>>>> >>>>>> >>>>> I may try that next time but the light had stopped blinking for several >>>>> minutes.  Since it is a SMR drive, I always leave it running until I >>>>> can't feel the heads bumping around.  I don't think it would be that >>>>> but, it's worth a try. It may lead to something.  >>>>> >>>>> Will update when it does it again.  >>>>> >>>>> Thanks. >>>>> >>>>> Dale >>>>> >>>>> :-)  :-)  >>>>> >>>> I had to wait until I was doing backups again to try anything.  The 6TB >>>> drive did fine.  The 8TB drive is giving the in use error.  The drive is >>>> unmounted but iotop didn't show anything and the light isn't blinking >>>> either.  I'd think if it was flushing cache the light would flash and it >>>> would not umount.  >>>> >>>> I tried the udev-trigger trick but it didn't work.  I don't know how >>>> long it will stay 'in use' so if anyone has ideas, think and type fast.  >>>> If not, may have to wait until next time to try again. >>>> >>>> Dale >>>> >>>> :-)  :-)  >>>> >>> Some more info: >>> >>> >>> root@fireball / # lvs >>>   LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log >>> Cpy%Sync Convert >>>   Home2  Home2  -wi-ao---- >>> <12.74t                                                    >>>   swap   OS     -wi-ao----  >>> 12.00g                                                    >>>   usr    OS     -wi-ao----  >>> 35.00g                                                    >>>   var    OS     -wi-ao----  >>> 52.00g                                                    >>>   backup backup -wi-ao---- >>> 698.63g                                                    >>> root@fireball / # vgs >>>   VG     #PV #LV #SN Attr   VSize    VFree  >>>   Home2    2   1   0 wz--n-  <12.74t      0 >>>   OS       1   3   0 wz--n- <124.46g <25.46g >>>   backup   1   1   0 wz--n-  698.63g      0 >>> root@fireball / # pvs >>>   PV         VG     Fmt  Attr PSize    PFree  >>>   /dev/sda7  OS     lvm2 a--  <124.46g <25.46g >>>   /dev/sdb1  Home2  lvm2 a--    <5.46t      0 >>>   /dev/sdc1  Home2  lvm2 a--    <7.28t      0 >>>   /dev/sdd1  backup lvm2 a--   698.63g      0 >>> root@fireball / # cryptsetup close 8tb >>> Device 8tb is still in use. >>> root@fireball / # >>> >>> >>> As you can see, lvm doesn't even show the device but it is still under >>> /dev as tho it is available.  Weird.  >>> >>> I found this but at the end, the command doesn't help me.  I'm not sure >>> why.  It does talk about using LUKS on top of LVM causing this problem.  >>> Since the fix doesn't work, is this a different problem?? >>> >>> >>> https://linux-blog.anracom.com/tag/device-still-in-use/ >>> >>> >>> I've tried every command I can find and it still shows busy.  I even >>> restarted udev and lvm.  Still busy.  >>> >>> Ideas? >>> >>> Dale >>> >>> :-)  :-)  >>> >> Found another tidbit of info that may shed some light on this problem.  >> I'm not sure what it means tho. >> >> >> >> root@fireball / # lsblk >> NAME              MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT >> <<>> >> sdj                 8:144  1   7.3T  0 disk  >> └─sdj1              8:145  1   7.3T  0 part  >>   └─8tb           254:5    0   7.3T  0 crypt /mnt/8tb >> sr0                11:0    1  1024M  0 rom   >> root@fireball / # >> >> >> So, something called crypt seems to have it open.  Now how do I tell it >> to go away?  Hmmmm.  Then I came up with this idea: >> >> >> root@fireball / # ps aux | grep crypt >> root       493  0.0  0.0      0     0 ?        I<   Jun13   0:00 [cryptd] >> root     11509  0.0  0.0   7728  2448 pts/2    S+   00:30   0:00 grep >> --colour=auto crypt >> root     23667  0.0  0.0      0     0 ?        I<   Jun20   0:00 >> [kcryptd_io/254:] >> root     23668  0.0  0.0      0     0 ?        I<   Jun20   0:00 >> [kcryptd/254:5] >> root     23669  0.0  0.0      0     0 ?        S    Jun20   0:00 >> [dmcrypt_write/2] >> root@fireball / # >> >> >> So kcryptd is the offender it seems since it matches MAJ:MIN info.  I >> assume that is kernel related not KDE.  Can I just kill that process?  >> Will it do damage if I kill it or is there a better way?  >> >> Dale >> >> :-)  :-)  >> > > After staring at it a while, it hit me that lsblk is showing it as still > mounted, even tho I umounted already without error.  So, I just ran the > umount command again.  After that, it closed just fine.  So, it seems to > be mounted twice, not once.  I mount using this command 'mount /mnt/8tb' > which uses fstab to mount the correct UUID device to that mount point.  > Surely it only mounts once.  Always has in the past.  So why is it being > mounted twice now?  None of my scripts used for backups includes any > mounting commands.  There's also only one entry in fstab as well.  > > Anyone have any idea while it gets mounted twice?  Does the cryptsetup > open command mount it in some way and then I mount it manually as well?? > When I opened it just now, it didn't show anything as mounted.  So it > doesn't appear to be the open command.  What else could it be?? > > Ideas?  > > Dale > > :-)  :-)  > The same drive just did it again.  I had to reboot to get it to reset.  This is Linux not windoze.  Rebooting to reset something like that is plain ridiculous.  I also checked, this time it was mounted only once.  When I tried to umount it again, it said it wasn't mounted.  The thing that really gets me, nothing can tell me what it is that is using the device.  It says it is in use but no clue what it is using it.  To test a theory, I changed fstab to mount by label instead of UUID.  Maybe that will change something.  I dunno.  I do know, if this doesn't improve soon, I'm going to erase the drive and either find another encryption tool or just not encrypt it at all.  I'm not rebooting every time this thing wants to act ugly.  I'm used to rebooting like every 6 months or so.  Usually when the power fails.  If anyone has any ideas, please post.  In the meantime, I'm going to try this mounting by label idea.  Dale :-)  :-)