Bug 754235 - mgetty is missing a lockdev support and that can cause conflicts with minicom or any other software that uses lockdev for locking
Summary: mgetty is missing a lockdev support and that can cause conflicts with minicom...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mgetty
Version: 17
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Michal Sekletar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-15 19:50 UTC by Dennis DeDonatis
Modified: 2014-09-08 15:08 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-30 04:40:33 UTC
Type: ---


Attachments (Terms of Use)
mgetty: use liblockdev for device locking (3.61 KB, patch)
2013-03-19 15:26 UTC, Michal Sekletar
jcapik: review+
Details | Diff

Description Dennis DeDonatis 2011-11-15 19:50:17 UTC
Description of problem:

Minicom ONLY writes lockfiles in /var/lock/lockdev/ and ignores the minirc "pu lock" setting.

Version-Release number of selected component (if applicable):

Version     : 2.5
Release     : 6.fc15

How reproducible:

Always

Steps to Reproduce:
1. minicom -s ttyUSB3
2. set option B under Serial port setup to /tmp
3. exit and then run minicom ttyUSB3
  
Actual results:

Lock files are in /var/lock/lockdev

Expected results:

Lock files should be in /tmp

Additional info:

I wanted to move the lock files to /var/lock so that mgetty would see the LCK..ttyUSB3 lock file.  mgetty doesn't have a configuration option to move the lock file or I'd just move it to /var/lock/lockdev, although this issue would still exist for minicom.

Comment 1 Jaromír Cápík 2011-11-16 16:59:17 UTC
Hello Dennis.

There are quite huge parts of the code disabled by patches made by the former minicom maintainer (it looks like these changes were inevitable). These parts are handling the lockfile manipulations and I believe they are directly related to the availability of lock filename settings.
This needs a deeper analysis. Otherwise I can't tell You if it is even possible to make the lock filename configurable again.

Regards,
Jaromir.

Comment 2 Fedora End Of Life 2012-08-07 16:26:31 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Fedora End Of Life 2013-01-16 22:47:53 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 4 Jaromír Cápík 2013-01-22 18:58:46 UTC
Hello Dennis.

The issue is reproducible even with the latest upstream release (2.6.1).

I've done a deeper analysis and found, that building minicom with lockdev support makes the lock path variable redundant/unused. The reason for this lies in the lockdev itself, since the lock path is hardcoded there and can't be configured on the fly. 

Hardcoding the lock path is generally a good idea. To avoid confusions the setup entry should be disabled when building with the lockdev support. I'm gonna fix that + send the patch upstream.

Thanks for the report.

Regards,
Jaromir.

Comment 5 Jaromír Cápík 2013-02-07 12:48:38 UTC
The patch has been accepted. I'm going to backport the change to older fedora releases.

Comment 6 Fedora Update System 2013-02-07 14:05:48 UTC
minicom-2.5-10.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/minicom-2.5-10.fc17

Comment 7 Fedora Update System 2013-02-07 14:06:10 UTC
minicom-2.5-10.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/minicom-2.5-10.fc18

Comment 8 Fedora Update System 2013-02-08 16:57:39 UTC
Package minicom-2.5-10.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing minicom-2.5-10.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-2127/minicom-2.5-10.fc18
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2013-02-19 01:27:31 UTC
minicom-2.5-10.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2013-02-19 01:29:49 UTC
minicom-2.5-10.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Dennis DeDonatis 2013-02-19 16:00:36 UTC
I tested this with minicom-2.5-10.fc17.

Option B in the serial port setup no longer exists, so there is no way to set a lock file through the program itself (minicom -s).

The minirc "pu lock" option is ignored if I manually add it to the minirc file.

minicom no longer gives the appearance that you can set the lockfile location.  You may want to update the man page as it still says you can move the lockfile:

"B - Lock file location  On most systems This should be /usr/spool/uucp. GNU/Linux systems use /var/lock. If this directory does not exist, minicom will not attempt to use lockfiles."

Although this seems to be what you wanted with this change, it doesn't solve the regression that I cannot run minicom and point it at a modem that mgetty is using like I could before the minicom lockfiles were moved (and hardcoded) to /var/lock/lockdev.

Comment 12 Jaromír Cápík 2013-02-19 16:42:44 UTC
Hello Denis.

Sorry, I forgot about that interoperability with mgetty you mentioned in the additional info.

Apparently the same problem was reported in the OpenSuSE bugzilla:

https://bugzilla.novell.com/show_bug.cgi?id=713330


I know it might look a bit buck passing, but I believe, that lockdev is the right way and we simply can't look back here. What we need is to write a lockdev support for mgetty. It shouldn't be difficult.

I'm changing the component to mgetty.

Hopefully Jindrich or Jan will manage that quickly.

Regards,
Jaromir.

Comment 13 Jaromír Cápík 2013-02-19 16:43:40 UTC
... and sorry for the missing 'n' in your name.

Comment 14 Michal Sekletar 2013-03-19 15:26:25 UTC
Created attachment 712767 [details]
mgetty: use liblockdev for device locking

Comment 15 Michal Sekletar 2013-03-19 15:27:55 UTC
Review and suggestions on attached patch are very welcome. Also please see [1], testing and feedback are very appreciated as well.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5142191

Comment 16 Jaromír Cápík 2013-03-20 18:07:30 UTC
Ahoj Michale.

I'll try to look at that during this or the next week.

Regards,
Jaromir.

Comment 17 Jaromír Cápík 2013-03-27 15:49:43 UTC
Ahoj Michale.

Could you please attach the whole srpm containing all the related modifications?

Thanks,
Jaromir.

Comment 18 Michal Sekletar 2013-03-28 12:13:28 UTC
Hi Jardo,

Sorry for inconvenience. Builds attached to certain scratch-build task could survive little longer in Koji :( . Anyway, here [1] it is.

[1] http://msekleta.fedorapeople.org/mgetty-1.1.36-20.fc20.src.rpm

Cheers,

Michal

Comment 19 Jaromír Cápík 2013-04-03 12:46:24 UTC
Ahoj Michale.

I've done some tests here and the locking seems to work correctly. Once I connect to the patched mgetty, minicom refuses to open the same device saying it's locked. When I test it without patching, minicom opens the device and breaks the communication. The source code changes also look reasonable, but I can't do a deeper analysis right now. I suggest you to let Dennis do his own tests and confirm whether it works or not.

Regards,
Jaromir.

Comment 20 Michal Sekletar 2013-04-03 16:10:00 UTC
Thank you for testing this out, it is much appreciated. Dennis it would be great if you could test the patch and provide some feedback. See [1] and find attached packages.

Regards,

Michal

[1] http://msekleta.fedorapeople.org/mgetty-lockdev/

Comment 21 Dennis DeDonatis 2013-04-04 15:57:46 UTC
This definitely seems to have fixed the issue.  Minicom and mgetty now play nice once again.  I can see the lock files in the lockdev directory for mgetty (and minicom).

Here's a snipit from the mgetty log file:

04/04 11:52:05 yS3   checking lockfiles, locking the line
04/04 11:52:05 yS3   makelock(ttyS3) called
04/04 11:52:05 yS3  lock not made: lock file exists (pid=23787)
04/04 11:52:05 yS3   lock file exists (dialout)!
04/04 11:52:05 yS3   lockfile found, pid=23787
04/04 11:52:05 yS3   utmp + wtmp entry made
04/04 11:52:05 yS3   lockfile found, pid=23787
04/04 11:52:15 yS3   lockfile found, pid=23787
04/04 11:52:25 yS3   lockfile found, pid=23787
04/04 11:52:35 yS3  checklock: device not locked
04/04 11:52:40 yS3  checklock: device not locked

Comment 22 Fedora Update System 2013-04-19 12:43:53 UTC
mgetty-1.1.36-20.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mgetty-1.1.36-20.fc19

Comment 23 Fedora Update System 2013-04-19 16:48:46 UTC
Package mgetty-1.1.36-20.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mgetty-1.1.36-20.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-6078/mgetty-1.1.36-20.fc19
then log in and leave karma (feedback).

Comment 24 Fedora Update System 2013-04-23 13:31:51 UTC
mgetty-1.1.36-21.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mgetty-1.1.36-21.fc19

Comment 25 Michal Sekletar 2013-04-23 13:44:03 UTC
In case you are wondering why yet another package should fix the issue, please note that I messed up previous update. It didn't passed Auto QA DEPCHECK, because of broken deps. I forgot /usr prefix for some required dependencies. I unpushed the previous update and released the new one. Sorry for inconvenience.

Testing and karma are always welcome. Also note that SELinux might prevent mgetty from locking device properly. I filled the bug against selinux-policy and it should be fixed in selinux-policy-3.12.1-35.

Comment 26 Fedora Update System 2013-04-30 04:40:35 UTC
mgetty-1.1.36-21.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.