Bug 754235

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.

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

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

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.

The patch has been accepted. I'm going to backport the change to older fedora releases.

minicom-2.5-10.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/minicom-2.5-10.fc17

minicom-2.5-10.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/minicom-2.5-10.fc18

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

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.

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.

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.

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.

... and sorry for the missing 'n' in your name.

Created attachment 712767 [details]
mgetty: use liblockdev for device locking

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

Ahoj Michale.

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

Regards,
Jaromir.

Ahoj Michale.

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

Thanks,
Jaromir.

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

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.

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/

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

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

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

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

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.

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.