Bug 727236

Summary:	switching the runlevel kills session
Product:	[openSUSE] openSUSE 12.1	Reporter:	Lars Müller <lmuelle>
Component:	Basesystem	Assignee:	Frederic Crozat <fcrozat>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	RC 1
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE 11.4
Whiteboard:
Found By:	Development	Services Priority:
Business Priority:		Blocker:	No
Marketing QA Status:	---	IT Deployment:	---

Description Lars Müller 2011-10-29 22:37:57 UTC

I had a session running on tty 6 in runlevel 5.  Calling init 3 killed the running bash.

The system makes use systemd.

Comment 1 Frederic Crozat 2011-10-31 12:57:00 UTC

just tested here and I couldn't reproduce.

Can you reproduce consistently ?

Comment 2 Lars Müller 2011-10-31 14:03:53 UTC

Yes.  I've tested it two times now.

Calling init 3 leads to a maybe 5 seconds delay till I get more than one login prompt.  Firt I only get one on tty 1.

Comment 3 Frederic Crozat 2011-10-31 14:11:11 UTC

could you give me output of 
ls /etc/systemd/system/getty.target.wants ?

Comment 4 Lars Müller 2011-10-31 20:44:58 UTC

lmuelle@giles:~> LC_ALL=POSIX ls -l /etc/systemd/system/getty.target.wants/
total 0
lrwxrwxrwx 1 root root 34 Oct 21 19:49 getty@tty1.service -> /lib/systemd/system/getty@.service
lmuelle@giles:~> runlevel 
N 5

Comment 5 Frederic Crozat 2011-11-04 14:58:18 UTC

ok, I had "old" configuration around.

This is a "know" upstream bug (causing also https://bugzilla.redhat.com/show_bug.cgi?id=708537 ) , because gettys (except the one on tty1) are started on demand and get killed when switching runlevel, not having RemainAfterExit flag (and they can't have this flag, since we want them to be restarted in normal conditions).

Until this is fixed, you can run :
for tty in tty2 tty3 tty4 tty5 tty6 ; do
  ln -s /lib/systemd/system/getty@.service /etc/systemd/system/getty@$tty.service
done

to make sure the tty will be always started.

Comment 6 Frederic Crozat 2013-03-11 15:17:20 UTC

Bug has been fixed upstream for some time now, and pushed to 12.1 and later. closing as fixed.

*** This bug has been marked as a duplicate of bug 746594 ***