Bug 947919 - mgetty is missing a systemd unit file
Summary: mgetty is missing a systemd unit file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mgetty
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Sekletar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-03 14:30 UTC by Jaromír Cápík
Modified: 2016-02-01 01:58 UTC (History)
10 users (show)

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


Attachments (Terms of Use)

Description Jaromír Cápík 2013-04-03 14:30:38 UTC
Hello.

mgetty (re)spawn used to be defined in /etc/inittab, but that way isn't available anymore due to the systemd introduction. We need to create a systemd unit file containing Restart=always and calling the mgetty binary. I would call mgetty without additional parameters and use the config file. Please, try to find the best way how to restore the mgetty respawning feature in all currently supported Fedora releases.

Thanks,
Jaromir.

P.S.: A similar problem has been reported in case of OpenSuSE ... there's a systemd unit file for ttyAM0 that can be reused/modified to become a universal one ... 

http://forums.opensuse.org/english/get-technical-help-here/applications/479617-opensuse-12-2-mgetty-systemd-dial-server-problem.html

Comment 1 Bill Nottingham 2013-04-04 14:25:13 UTC
This would be a service that's off by default but could be enabled by the admin if they wanted to?

Comment 2 Michal Sekletar 2013-04-04 15:17:48 UTC
I am currently experimenting with similar scheme as used in case of agetty on VT. I will introduce mgetty.target and mgetty@.service. getty.target is special (see systemd.special) and I'd say that it should be the case of mgetty.target too.
Otherwise we can leave it on admin to enable, both target and instances.

Bill, what makes better sense to you?

Comment 3 Bill Nottingham 2013-04-04 15:21:23 UTC
mgetty@.service sounds more systemd-ish, but using the system mgetty configuration would make more 'sense' to existing users of mgetty, I expect. I could see either way.

Comment 4 Lennart Poettering 2013-04-04 20:35:43 UTC
I'd recommend to reuse getty.target for mgetty@service. It already is where we hook in fixed VT gettys and serial agettys, so adding in mgetty to the same target sounds ok.

Comment 5 Michal Sekletar 2013-04-04 20:45:13 UTC
Originally, I've had mgetty.target in mind, but if you don't mind hooking in mgetty instances to getty.target, that is even better.

Comment 6 Fedora Update System 2013-04-19 12:44:06 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 7 Fedora Update System 2013-04-19 16:48:55 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 8 Fedora Update System 2013-04-23 13:32:06 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 9 Fedora Update System 2013-04-30 04:40:50 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.