Getting a serial console to work on Jessie
Hello,
I have a bunch of Debian Wheezy servers set up with the console available
via the serial port. Generally, I just add this line to /etc/inittab:
co:2345:respawn:/sbin/getty -L ttyS0 9600 vt102
And then run "kill -HUP 1" and the serial console works (I could also use
"telinit q" or "init q" instead of kill -HUP"). I just did this on a
Wheezy server to make sure, and checked the getty processes prior to making
the change:
# ps -ef | grep getty
root 2660 1 0 Jul24 tty1 00:00:00 /sbin/getty 38400 tty1
root 2661 1 0 Jul24 tty2 00:00:00 /sbin/getty 38400 tty2
root 2662 1 0 Jul24 tty3 00:00:00 /sbin/getty 38400 tty3
root 2663 1 0 Jul24 tty4 00:00:00 /sbin/getty 38400 tty4
root 2664 1 0 Jul24 tty5 00:00:00 /sbin/getty 38400 tty5
root 2665 1 0 Jul24 tty6 00:00:00 /sbin/getty 38400 tty6
And then after:
# ps -ef | grep getty
root 2660 1 0 Jul24 tty1 00:00:00 /sbin/getty 38400 tty1
root 2661 1 0 Jul24 tty2 00:00:00 /sbin/getty 38400 tty2
root 2662 1 0 Jul24 tty3 00:00:00 /sbin/getty 38400 tty3
root 2663 1 0 Jul24 tty4 00:00:00 /sbin/getty 38400 tty4
root 2664 1 0 Jul24 tty5 00:00:00 /sbin/getty 38400 tty5
root 2665 1 0 Jul24 tty6 00:00:00 /sbin/getty 38400 tty6
root 31705 1 0 11:33 ttyS000:00:00 /sbin/getty -L ttyS0 9600
vt102
And there's the getty on ttyS0 as expected.
That's all fine and good, but when I try to do this on my desktop PC
running Jessie, it doesn't work. My PC is running an X server, Gnome,
etc., whereas the servers are not. Also, on Wheezy, /sbin/getty and
/sbin/agetty seem to be two copies of the same file, wheras on Jessie,
/sbin/getty is a symlink to /sbin/agetty.
The PC is using the default /etc/inittab file. When I check the list of
getty processes after a clean reboot, there's only this:
# ps -ef | grep getty
root 2092 1 0 11:50 tty1 00:00:00 /sbin/agetty --noclear tty1
linux
If I access the virtual consoles via CTRL-ALT-F1, etc., they show up in the
process list only after they have been accessed:
# ps -ef | grep getty
root 2092 1 0 11:50 tty1 00:00:00 /sbin/agetty --noclear tty1
linux
root 2998 1 0 11:56 tty2 00:00:00 /sbin/agetty --noclear tty2
linux
root 3001 1 0 11:56 tty3 00:00:00 /sbin/agetty --noclear tty3
linux
And still not in the same way that they appear on Wheezy ("/sbin/getty
38400 tty1", etc.). If I add the line for the serial console to
/etc/inittab and reload the init deamon, or even reboot the PC, it simply
does nothing. No getty process shows up on ttyS0, and no serial console is
available.
I know the serial port itself works, because I can connect to it from my
laptop, then do "screen /dev/ttyS0 9600" on the PC and see characters in
the screen session as I type them on the laptop. So the serial port works,
and I/O seems to work, but I can't seem to start a persistent getty process
on that port and access the console through it.
Any ideas or suggestions are very much appreciated.
Thanks!
Dave
--
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177
Re: Getting a serial console to work on Jessie
Am 01.09.2015 um 18:13 schrieb David Parker:
> And still not in the same way that they appear on Wheezy ("/sbin/getty
> 38400 tty1", etc.). If I add the line for the serial console to
> /etc/inittab and reload the init deamon, or even reboot the PC, it simply
> does nothing. No getty process shows up on ttyS0, and no serial console is
> available.
>
> I know the serial port itself works, because I can connect to it from my
> laptop, then do "screen /dev/ttyS0 9600" on the PC and see characters in
> the screen session as I type them on the laptop. So the serial port works,
> and I/O seems to work, but I can't seem to start a persistent getty process
> on that port and access the console through it.
Reading your description, I assume you have systemd-sysv installed and
systemd is your active PID 1. systemd no longer reads /etc/inittab, so
any configuration changes there don't have any effect.
getty's are started on demand by systemd-logind [1] and then show up as
instances of getty@.service, e.g. getty@tty1.service.
If you wanted to see your currently running instances you could use
something like "systemctl list-units | grep getty@"
For getty's on a serial console, there is a serial-getty@.service unit,
which is also started on demand.
If for some reason you want to enable those units statically, i.e.
always start them during boot, then this is no problem either.
Run
systemctl enable getty@tty2.service
systemctl enable getty@tty3.service
..
systemctl enable serial-getty@ttyS0.service
etc.
Regards,
Michael
[1] see man logind.conf -> NAutoVTs
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Re: Getting a serial console to work on Jessie
Am 01.09.2015 um 19:31 schrieb David Parker: > Thanks, Michael! That was indeed the problem. I > copied /lib/systemd/system/serial-getty@.service to /etc/systemd/system, > edited it to use the correct baud rate and terminal type, and then ran > "systsystemctl start serial-getty@ttyS0.service" and it worked like a charm. Glad we could solve your problem this easily. As for overriding the system provided service files, I usually recommend to use drop-ins, i.e. creating a /etc/systemd/system/foo.service.d/my_custom_config.conf This way you only need to override what you are actually interested in. You can use drop-ins for template files itself or for instances itself: /etc/systemd/system/serial-getty@.service.d/my_stuff.conf -> will apply to all instances of serial-getty@ /etc/systemd/system/serial-getty@ttyS0.service.d/my_stuff.conf -> only applies to serial-getty@ttyS0.service.d > Guess I need to get with the times and learn systemd! Welcome! Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Getting a serial console to work on Jessie
Michael Biebl wrote: > As for overriding the system provided service files, I usually recommend > to use drop-ins, i.e. creating a > /etc/systemd/system/foo.service.d/my_custom_config.conf > This way you only need to override what you are actually interested in. Users of Testing/Stretch or Unstable/Sid can use systemctl directly: # systemctl edit foo.service and this will create the override directory in the right place and open a new file in your preferred editor. Very handy. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Getting a serial console to work on Jessie
On Tue, 01 Sep 2015 12:13:56 -0400 (EDT), David Parker wrote: > > I have a bunch of Debian Wheezy servers set up with the console available > via the serial port. Generally, I just add this line to /etc/inittab: > ... > That's all fine and good, but when I try to do this on my desktop PC > running Jessie, it doesn't work. > ... I realize that you already have a resolution to your problem, but if you're using serial consoles on Debian Linux, you might find some useful information here: http://users.wowway.com/~zlinuxman/serial.htm -- .''`. Stephen Powell : :' : `. `'` `-
Re: Getting a serial console to work on Jessie
Thanks. I actually found that site in a Google search, and it's where I found the tip on copying the /lib/systemd/system/serial-getty@.service template file to customize the baud rate, etc. Specifically, I found the info I needed at: http://users.wowway.com/~zlinuxman/serial.htm#Systemd Thanks! On Tue, Sep 1, 2015 at 6:43 PM, Stephen Powell wrote: > On Tue, 01 Sep 2015 12:13:56 -0400 (EDT), David Parker wrote: > > > > I have a bunch of Debian Wheezy servers set up with the console available > > via the serial port. Generally, I just add this line to /etc/inittab: > > ... > > That's all fine and good, but when I try to do this on my desktop PC > > running Jessie, it doesn't work. > > ... > > I realize that you already have a resolution to your problem, but if you're > using serial consoles on Debian Linux, you might find some useful > information here: > >http://users.wowway.com/~zlinuxman/serial.htm > > -- > .''`. Stephen Powell > : :' : > `. `'` >`- > > -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Getting a serial console to work on Jessie
David Parker wrote: > Thanks. I actually found that site in a Google search, and it's where > I found the tip on copying the > /lib/systemd/system/serial-getty@.service template file to customize > the baud rate, etc. Specifically, I found the info I needed at: > http://users.wowway.com/~zlinuxman/serial.htm#Systemd Well, the advise given on that website is wrong, or at least suboptimal, because it totally overrides the system configuration instead of only ammending it, which preserves future changes to the system file. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Getting a serial console to work on Jessie
On Wednesday 02 September 2015 20:58:29 Sven Hartge wrote: > David Parker wrote: > > Thanks. I actually found that site in a Google search, and it's where > > I found the tip on copying the > > /lib/systemd/system/serial-getty@.service template file to customize > > the baud rate, etc. Specifically, I found the info I needed at: > > > > http://users.wowway.com/~zlinuxman/serial.htm#Systemd > > Well, the advise given on that website is wrong, or at least suboptimal, > because it totally overrides the system configuration instead of only > ammending it, which preserves future changes to the system file. > > Grüße, > Sven. Sven, May I kindly ask you to elaborate on that? Please, because I'm interested too. Where is better information to be had or can you at least point out where exactly one needs to start to iron out the failings of the mentioned document? I'm not exactly understanding what you mean by "preserves future changes to the system file". I always had the impression that my changes to config files can either be overwritten by updates (bad), merged into the newer config files (difficult without administrator intervention) or left alone and new config files installed as "release" files, or the new files installed and the old ones backed-up as *.pkg-old. Preserves seem always to be from the past yield, can the future be preserved? Also, what do you mean exactly by "system file" in the case of systemd - those in /lib/systemd/system/? Cheers and thank you Eike
Re: Getting a serial console to work on Jessie
Eike Lantzsch wrote:
> On Wednesday 02 September 2015 20:58:29 Sven Hartge wrote:
>> David Parker wrote:
>>> Thanks. I actually found that site in a Google search, and it's where
>>> I found the tip on copying the
>>> /lib/systemd/system/serial-getty@.service template file to customize
>>> the baud rate, etc. Specifically, I found the info I needed at:
>>>
>>> http://users.wowway.com/~zlinuxman/serial.htm#Systemd
>> Well, the advise given on that website is wrong, or at least suboptimal,
>> because it totally overrides the system configuration instead of only
>> ammending it, which preserves future changes to the system file.
> May I kindly ask you to elaborate on that? Please, because I'm
> interested too. Where is better information to be had or can you at
> least point out where exactly one needs to start to iron out the
> failings of the mentioned document?
> I'm not exactly understanding what you mean by "preserves future
> changes to the system file". I always had the impression that my
> changes to config files can either be overwritten by updates (bad),
> merged into the newer config files (difficult without administrator
> intervention) or left alone and new config files installed as
> "release" files, or the new files installed and the old ones backed-up
> as *.pkg-old.
> Preserves seem always to be from the past yield, can the future be
> preserved?
> Also, what do you mean exactly by "system file" in the case of systemd
> - those in /lib/systemd/system/?
Please excuse this misunderstanding, my native language got the better
of me in that case. "system file" means "the one from the package".
Now, the explanation:
systemd provides a way to override or ammend parts of units. You do this
by creating a directory structure like this:
/etc/systemd/system/foo.service.d/
This will contain all additional config files for the unit
"foo.service".
For example: I don't want systemd to clear the screen on tty1 when it
starts a new getty. The unit responsible for this TTY is named
"getty@tty1.service". I created
/etc/systemd/system/getty@tty1.service.d
and put a file named "noclear.conf" in it with this content:
,
| [Service]
| TTYVTDisallocate=no
`
This will add (or change) the TTYVTDisallocate option to the unit.
The original path to the unit is "/lib/systemd/system/getty@.service"
and if this file is changed by a package update, its new content will be
used.
If I had copied the _whole_ file to /etc/systemd/system then the new
version of the unit in "/lib/systemd/system" would never get used, just
my own version. This may be fine but may also cause major problems in
the future.
This is what I meant by "future changes are preserved" as you don't just
clobber them with your own full copy of the (then) old unit file.
You can check which files are used for a unit with systemctl:
systemctl cat getty@tty1.service
and you will get an output like this (a bit shortened by me for this
mail):
,
| # /lib/systemd/system/getty@.service
|
| [Unit]
| Description=Getty on %I
| Documentation=man:agetty(8) man:systemd-getty-generator(8)
| Documentation=http://0pointer.de/blog/projects/serial-console.html
| After=systemd-user-sessions.service plymouth-quit-wait.service
| <<8<--->>
| [Service]
| # the VT is cleared by TTYVTDisallocate
| TTYVTDisallocate=yes
| KillMode=process
| IgnoreSIGPIPE=no
| SendSIGHUP=yes
|
| # Unset locale for the console getty since the console has problems
| # displaying some internationalized messages.
| Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE=
| LC_MONETARY= LC_MESSAGES= LC_
|
| [Install]
| WantedBy=getty.target
| DefaultInstance=tty1
|
| # /etc/systemd/system/getty@tty1.service.d/noclear.conf
| [Service]
| TTYVTDisallocate=no
`
Note how my own addition shows up at the bottom.
Also note how a later "TTYVTDisallocate=no" overrides the earlier
"TTYVTDisallocate=yes".
You can also use "systemd-delta" to check which units have overrides or
extentions. And with newer systemd (Stretch and newer) you can even use
"systemctl edit unitname" and it will create the needed directory
structure in the correct place for you.
But you are also correct that this "override feature" is a bit different
than the normal proceedings during upgrades and dealing with
.dpkg-{old,new,dist}.
But it is the way systemd is designed and you can either work with it or
fight it every centimeter of the way.
I hope this explains my thoughts.
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
Re: Getting a serial console to work on Jessie
On Wednesday 02 September 2015 23:29:40 Sven Hartge wrote:
> Eike Lantzsch wrote:
> > On Wednesday 02 September 2015 20:58:29 Sven Hartge wrote:
> >> David Parker wrote:
> >>> Thanks. I actually found that site in a Google search, and it's where
> >>> I found the tip on copying the
> >>> /lib/systemd/system/serial-getty@.service template file to customize
> >>> the baud rate, etc. Specifically, I found the info I needed at:
> >>>
> >>> http://users.wowway.com/~zlinuxman/serial.htm#Systemd
> >>
> >> Well, the advise given on that website is wrong, or at least suboptimal,
> >> because it totally overrides the system configuration instead of only
> >> ammending it, which preserves future changes to the system file.
> >
> > May I kindly ask you to elaborate on that? Please, because I'm
> > interested too. Where is better information to be had or can you at
> > least point out where exactly one needs to start to iron out the
> > failings of the mentioned document?
> >
> > I'm not exactly understanding what you mean by "preserves future
> > changes to the system file". I always had the impression that my
> > changes to config files can either be overwritten by updates (bad),
> > merged into the newer config files (difficult without administrator
> > intervention) or left alone and new config files installed as
> > "release" files, or the new files installed and the old ones backed-up
> > as *.pkg-old.
> >
> > Preserves seem always to be from the past yield, can the future be
> > preserved?
> >
> > Also, what do you mean exactly by "system file" in the case of systemd
> > - those in /lib/systemd/system/?
>
> Please excuse this misunderstanding, my native language got the better
> of me in that case. "system file" means "the one from the package".
>
> Now, the explanation:
>
> systemd provides a way to override or ammend parts of units. You do this
> by creating a directory structure like this:
>
> /etc/systemd/system/foo.service.d/
>
> This will contain all additional config files for the unit
> "foo.service".
>
> For example: I don't want systemd to clear the screen on tty1 when it
> starts a new getty. The unit responsible for this TTY is named
> "getty@tty1.service". I created
>
> /etc/systemd/system/getty@tty1.service.d
>
> and put a file named "noclear.conf" in it with this content:
>
> ,
>
> | [Service]
> | TTYVTDisallocate=no
>
> `
>
> This will add (or change) the TTYVTDisallocate option to the unit.
> The original path to the unit is "/lib/systemd/system/getty@.service"
> and if this file is changed by a package update, its new content will be
> used.
>
> If I had copied the _whole_ file to /etc/systemd/system then the new
> version of the unit in "/lib/systemd/system" would never get used, just
> my own version. This may be fine but may also cause major problems in
> the future.
>
> This is what I meant by "future changes are preserved" as you don't just
> clobber them with your own full copy of the (then) old unit file.
>
> You can check which files are used for a unit with systemctl:
>
> systemctl cat getty@tty1.service
>
> and you will get an output like this (a bit shortened by me for this
> mail):
>
> ,
>
> | # /lib/systemd/system/getty@.service
> |
> | [Unit]
> | Description=Getty on %I
> | Documentation=man:agetty(8) man:systemd-getty-generator(8)
> | Documentation=http://0pointer.de/blog/projects/serial-console.html
> | After=systemd-user-sessions.service plymouth-quit-wait.service
> | <<8<--->>
> | [Service]
> | # the VT is cleared by TTYVTDisallocate
> | TTYVTDisallocate=yes
> | KillMode=process
> | IgnoreSIGPIPE=no
> | SendSIGHUP=yes
> |
> | # Unset locale for the console getty since the console has problems
> | # displaying some internationalized messages.
> | Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE=
> | LC_MONETARY= LC_MESSAGES= LC_
> |
> | [Install]
> | WantedBy=getty.target
> | DefaultInstance=tty1
> |
> | # /etc/systemd/system/getty@tty1.service.d/noclear.conf
> | [Service]
> | TTYVTDisallocate=no
>
> `
>
> Note how my own addition shows up at the bottom.
>
> Also note how a later "TTYVTDisallocate=no" overrides the earlier
> "TTYVTDisallocate=yes".
>
> You can also use "systemd-delta" to check which units have overrides or
> extentions. And with newer systemd (Stretch and newer) you can even use
> "systemctl edit unitname" and it will create the needed directory
> structure in the correct place for you.
>
> But you are also correct that this "override feature" is a bit different
> than the normal proceedings during upgrades and dealing with
> .dpkg-{old,new,dist}.
>
> But it is the way systemd is designed and you can either work with it or
> fight it every centimeter of the way.
I sure won't fight anything I do not thoroughly understand. That's always a
means to lose.
>
> I hope this explains my thoughts.
Very well.
>
> Grüße,
> Sven.
Thank you Sven!
This clears things up and sends me fur
Re: Getting a serial console to work on Jessie
On Wed, 02 Sep 2015 17:29:40 -0400 (EDT), Sven Hartge wrote: > ... > > systemd provides a way to override or ammend parts of units. > You do this by creating a directory structure like this: > > /etc/systemd/system/foo.service.d/ > > This will contain all additional config files for the unit > "foo.service". > > For example: I don't want systemd to clear the screen on tty1 when it > starts a new getty. The unit responsible for this TTY is named > "getty@tty1.service". I created > > /etc/systemd/system/getty@tty1.service.d > > and put a file named "noclear.conf" in it with this content: > > , > | [Service] > | TTYVTDisallocate=no > ` > > This will add (or change) the TTYVTDisallocate option to the unit. > The original path to the unit is "/lib/systemd/system/getty@.service" > and if this file is changed by a package update, its new content will be > used. > > If I had copied the _whole_ file to /etc/systemd/system then the new > version of the unit in "/lib/systemd/system" would never get used, just > my own version. This may be fine but may also cause major problems in > the future. > > This is what I meant by "future changes are preserved" as you don't just > clobber them with your own full copy of the (then) old unit file. > > You can check which files are used for a unit with systemctl: > > systemctl cat getty@tty1.service > > and you will get an output like this (a bit shortened by me for this > mail): > > , > | # /lib/systemd/system/getty@.service > | > | [Unit] > | Description=Getty on %I > | Documentation=man:agetty(8) man:systemd-getty-generator(8) > | Documentation=http://0pointer.de/blog/projects/serial-console.html > | After=systemd-user-sessions.service plymouth-quit-wait.service > | <<8<--->> > | [Service] > | # the VT is cleared by TTYVTDisallocate > | TTYVTDisallocate=yes > | KillMode=process > | IgnoreSIGPIPE=no > | SendSIGHUP=yes > | > | # Unset locale for the console getty since the console has problems > | # displaying some internationalized messages. > | Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= > | LC_MONETARY= LC_MESSAGES= LC_ > | > | [Install] > | WantedBy=getty.target > | DefaultInstance=tty1 > | > | # /etc/systemd/system/getty@tty1.service.d/noclear.conf > | [Service] > | TTYVTDisallocate=no > ` > > Note how my own addition shows up at the bottom. > > Also note how a later "TTYVTDisallocate=no" overrides the earlier > "TTYVTDisallocate=yes". > > You can also use "systemd-delta" to check which units have overrides or > extentions. And with newer systemd (Stretch and newer) you can even use > "systemctl edit unitname" and it will create the needed directory > structure in the correct place for you. Thanks for the tip, Sven. I'll try to incorporate your suggestion in the next revision of my serial console document. With luck, I may get to it this weekend. Do you know a similar technique for overriding individual udev rules in a system-provided rules file? -- .''`. Stephen Powell : :' : `. `'` `-
Re: Getting a serial console to work on Jessie
Stephen Powell wrote: > Do you know a similar technique for overriding individual udev rules in > a system-provided rules file? Ah, that part is a white spot on my (mind)map. Maybe Michael Biebl can provide more input, as one of the DDs maintaining systemd and udev he should be able to provide more input. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Getting a serial console to work on Jessie
Am 03.09.2015 um 03:14 schrieb Stephen Powell: > Do you know a similar technique for overriding individual udev rules in > a system-provided rules file? A similar mechanism exists for udev rules file. See man 7 udev -> "RULES FILES" -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Getting a serial console to work on Jessie
On Thu, 03 Sep 2015 20:06:43 -0400 (EDT), Michael Biebl wrote: > > Am 03.09.2015 um 03:14 schrieb Stephen Powell: >> Do you know a similar technique for overriding individual udev rules in >> a system-provided rules file? > > A similar mechanism exists for udev rules file. > See man 7 udev -> "RULES FILES" I do know about user-written rules files, and I have used them in the past, but for some reason it never occurred to me to use a user-written rule to change an already-applied system-written rule. Duh! Why didn't I think of that? How embarrassing! Thanks. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Getting a serial console to work on Jessie
On Wed, 02 Sep 2015 17:29:40 -0400 (EDT), Sven Hartge wrote:
>
> systemd provides a way to override or ammend parts of units. You do this
> by creating a directory structure like this:
>
> /etc/systemd/system/foo.service.d/
>
> This will contain all additional config files for the unit
> "foo.service".
>
> For example: I don't want systemd to clear the screen on tty1 when it
> starts a new getty. The unit responsible for this TTY is named
> "getty@tty1.service". I created
>
> /etc/systemd/system/getty@tty1.service.d
>
> and put a file named "noclear.conf" in it with this content:
>
> ,
> | [Service]
> | TTYVTDisallocate=no
> `
>
> This will add (or change) the TTYVTDisallocate option to the unit.
> The original path to the unit is "/lib/systemd/system/getty@.service"
> and if this file is changed by a package update, its new content will be
> used.
>
> If I had copied the _whole_ file to /etc/systemd/system then the new
> version of the unit in "/lib/systemd/system" would never get used, just
> my own version. This may be fine but may also cause major problems in
> the future.
>
> This is what I meant by "future changes are preserved" as you don't just
> clobber them with your own full copy of the (then) old unit file.
>
> You can check which files are used for a unit with systemctl:
>
> systemctl cat getty@tty1.service
>
> and you will get an output like this (a bit shortened by me for this
> mail):
>
> ,
> | # /lib/systemd/system/getty@.service
> |
> | [Unit]
> | Description=Getty on %I
> | Documentation=man:agetty(8) man:systemd-getty-generator(8)
> | Documentation=http://0pointer.de/blog/projects/serial-console.html
> | After=systemd-user-sessions.service plymouth-quit-wait.service
> | <<8<--->>
> | [Service]
> | # the VT is cleared by TTYVTDisallocate
> | TTYVTDisallocate=yes
> | KillMode=process
> | IgnoreSIGPIPE=no
> | SendSIGHUP=yes
> |
> | # Unset locale for the console getty since the console has problems
> | # displaying some internationalized messages.
> | Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE=
> | LC_MONETARY= LC_MESSAGES= LC_
> |
> | [Install]
> | WantedBy=getty.target
> | DefaultInstance=tty1
> |
> | # /etc/systemd/system/getty@tty1.service.d/noclear.conf
> | [Service]
> | TTYVTDisallocate=no
> `
>
> Note how my own addition shows up at the bottom.
>
> Also note how a later "TTYVTDisallocate=no" overrides the earlier
> "TTYVTDisallocate=yes".
>
> You can also use "systemd-delta" to check which units have overrides or
> extentions. And with newer systemd (Stretch and newer) you can even use
> "systemctl edit unitname" and it will create the needed directory
> structure in the correct place for you.
>
> But you are also correct that this "override feature" is a bit different
> than the normal proceedings during upgrades and dealing with
> .dpkg-{old,new,dist}.
>
> But it is the way systemd is designed and you can either work with it or
> fight it every centimeter of the way.
>
Well, Sven, that's a nice idea, but I can't get it to work for me in this
situation. I issued
systemctl edit serial-getty@ttyS0.service
and placed the following two lines into the file:
[Service]
ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151
But when I restart the service, I get the following error:
systemd[1]: serial-getty@ttyS0.service: Service has more than one ExecStart=
setting, which is only allowed for Type=oneshot services. Refusing.
I want to override "ExecStart", not add a new one. What am I doing wrong?
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Re: Getting a serial console to work on Jessie
Am 06.09.2015 um 21:04 schrieb Stephen Powell: >[Service] >ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151 > > But when I restart the service, I get the following error: > > systemd[1]: serial-getty@ttyS0.service: Service has more than one ExecStart= > setting, which is only allowed for Type=oneshot services. Refusing. > > I want to override "ExecStart", not add a new one. What am I doing wrong? By default, systemd will simply merge all drop-ins. In your case, ExecStart is a setting which can not be specified more then once. So you need to "clear" it first. The following should do the trick: [Service] ExecStart= ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151 The "ExecStart=" resets the existing setting. See also man 5 systemd.unit , "Example 2. Overriding vendor settings": >Note that for drop-in files, if one wants to remove entries from a > setting that is >parsed as a list (and is not a dependency), such as > ConditionPathExists= (or e.g. >ExecStart= in service units), one needs to first clear the list before > re-adding all >entries except the one that is to be removed. See below for an example. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Getting a serial console to work on Jessie
Stephen Powell wrote: > Well, Sven, that's a nice idea, but I can't get it to work for me in this > situation. I issued >systemctl edit serial-getty@ttyS0.service > and placed the following two lines into the file: >[Service] >ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151 > But when I restart the service, I get the following error: > systemd[1]: serial-getty@ttyS0.service: Service has more than one ExecStart= > setting, which is only allowed for Type=oneshot services. Refusing. > I want to override "ExecStart", not add a new one. What am I doing wrong? You have to first clear the old ExecStart and then set a new one: https://wiki.archlinux.org/index.php/Systemd#Drop-in_snippets , | As another example, in order to replace the ExecStart directive for a unit | that is not of type oneshot, create the following file: | , | | /etc/systemd/system/unit.d/customexec.conf | | [Service] | | ExecStart= | | ExecStart=new command | ` ` Yes, this is a bit counterintuitive. So, in your case, the config file should look like this: , | [Service] | ExecStart= | ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151 ` Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Getting a serial console to work on Jessie
Hello Michael, On 09/06/2015 10:06 PM, Michael Biebl wrote: > See also man 5 systemd.unit , "Example 2. Overriding vendor settings": > >>Note that for drop-in files, if one wants to remove entries from a >> setting that is >>parsed as a list (and is not a dependency), such as >> ConditionPathExists= (or e.g. >>ExecStart= in service units), one needs to first clear the list >> before re-adding all >>entries except the one that is to be removed. See below for an >> example. Note that that passage in the man page is only present in versions of systemd beginning with either 216 or 217, while Jessie only has systemd 215, and thus the man pages in Jessie don't contain that text yet. Christian signature.asc Description: OpenPGP digital signature
Re: Getting a serial console to work on Jessie
On Sun, 06 Sep 2015 16:06:35 -0400 (EDT), Michael Biebl wrote: > Am 06.09.2015 um 21:04 schrieb Stephen Powell: >> ... >>[Service] >>ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151 >> >> But when I restart the service, I get the following error: >> >> systemd[1]: serial-getty@ttyS0.service: Service has more than one ExecStart= >> setting, which is only allowed for Type=oneshot services. Refusing. >> >> I want to override "ExecStart", not add a new one. What am I doing wrong? > > By default, systemd will simply merge all drop-ins. > In your case, ExecStart is a setting which can not be specified more > then once. So you need to "clear" it first. The following should do the > trick: > > [Service] > ExecStart= > ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151 > > > The "ExecStart=" resets the existing setting. > > ... That works. This is definitely a better solution than copying serial-getty@.service from /lib/systemd/system to /etc/systemd/system and then editing the copy in /etc/systemd/system to change the ExecStart value. It is better for two reasons: (1) When systemd is serviced, I don't need to recopy and reedit the file in order to keep my changes synced up with changes to the file made by service to systemd. (2) It allows two different serial ports to have different ExecStart values for two different terminal types, for example. Using my original method, both serial ports would be locked into the same terminal type. I shall change my documentation accordingly. Thanks, Michael and Sven for your suggestions and help. Regards, -- .''`. Stephen Powell : :' : `. `'` `-
Re: Getting a serial console to work on Jessie
Hello, Thanks for all the clarification. I now find myself in need of doing this again on another server running Jessie, and I just want to make sure I'm clear on what the best procedure is. As I understand it, I should copy /lib/systemd/system/serial-getty@.service to /etc/systemd/system/serial-getty@ttyS0.service, then edit serial-getty@ttyS0.service to include the following: [Service] ExecStart= ExecStart=-/sbin/agetty -8 --noclear %I 9600 vt100 ... Is that correct? Thanks! Dave On Sun, Sep 6, 2015 at 9:52 PM, Stephen Powell wrote: > On Sun, 06 Sep 2015 16:06:35 -0400 (EDT), Michael Biebl wrote: > > Am 06.09.2015 um 21:04 schrieb Stephen Powell: > >> ... > >>[Service] > >>ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151 > >> > >> But when I restart the service, I get the following error: > >> > >> systemd[1]: serial-getty@ttyS0.service: Service has more than one > ExecStart= setting, which is only allowed for Type=oneshot services. > Refusing. > >> > >> I want to override "ExecStart", not add a new one. What am I doing > wrong? > > > > By default, systemd will simply merge all drop-ins. > > In your case, ExecStart is a setting which can not be specified more > > then once. So you need to "clear" it first. The following should do the > > trick: > > > > [Service] > > ExecStart= > > ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151 > > > > > > The "ExecStart=" resets the existing setting. > > > > ... > > That works. This is definitely a better solution than copying > serial-getty@.service from /lib/systemd/system to /etc/systemd/system > and then editing the copy in /etc/systemd/system to change the ExecStart > value. It is better for two reasons: > > (1) When systemd is serviced, I don't need to recopy and reedit the file > in order to keep my changes synced up with changes to the file made by > service to systemd. > > (2) It allows two different serial ports to have different ExecStart values > for two different terminal types, for example. Using my original method, > both serial ports would be locked into the same terminal type. > > I shall change my documentation accordingly. Thanks, Michael and Sven > for your suggestions and help. > > Regards, > > -- > .''`. Stephen Powell > : :' : > `. `'` >`- > > -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Getting a serial console to work on Jessie
On Mon, 07 Sep 2015 09:56:12 -0400 (EDT), David Parker wrote: > > Thanks for all the clarification. I now find myself in need of doing this > again on another server running Jessie, and I just want to make sure I'm > clear on what the best procedure is. > ... I just finished updating my web page to reflect the new information. Once again, go to http://users.wowway.com/~zlinuxman/serial.htm Make sure that you press F5 to refresh the page (or whatever your browser's refresh key is), since an old version of the page may be in your browser's cache if you've looked at it recently. Then read the new instructions for enabling a serial terminal under systemd. If you then have any questions, please post a follow-up. Sven and Michael, please review this also and correct me if I made a mistake. I do not want to publish bad advice. Regards, -- .''`. Stephen Powell : :' : `. `'` `-
Re: Getting a serial console to work on Jessie
Stephen Powell wrote: > Sven and Michael, please review this also and correct me if I made a > mistake. I do not want to publish bad advice. Looks fine, from a cursory glance. Maybe you can add a section about using "systemctl cat serial-getty@ttyS0.service" to verfiy that the override.conf has been read successfully after "systemctl daemon-reload". Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Getting a serial console to work on Jessie
On Mon, 7 Sep 2015, Stephen Powell wrote: I just finished updating my web page to reflect the new information. Once again, go to http://users.wowway.com/~zlinuxman/serial.htm What a great contribution! My null-modem cable ought to still be around here somewhere! :-) -- Bob Bernstein
Re: Getting a serial console to work on Jessie
On Mon, 07 Sep 2015 11:47:56 -0400 (EDT), Sven Hartge wrote: > > Looks fine, from a cursory glance. > > Maybe you can add a section about using > >"systemctl cat serial-getty@ttyS0.service" > > to verfiy that the override.conf has been > read successfully after "systemctl daemon-reload". Done. Refresh the page and see if that's what you had in mind. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Getting a serial console to work on Jessie
On Mon, 07 Sep 2015 18:08:05 -0400 (EDT), Bob Bernstein wrote: > > What a great contribution! > > My null-modem cable ought to still be around here somewhere! > > :-) I try to focus on the latest technology. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Getting a serial console to work on Jessie
Stephen Powell wrote: > On Mon, 07 Sep 2015 11:47:56 -0400 (EDT), Sven Hartge wrote: >> Looks fine, from a cursory glance. >> >> Maybe you can add a section about using >> >>"systemctl cat serial-getty@ttyS0.service" >> >> to verfiy that the override.conf has been >> read successfully after "systemctl daemon-reload". > Done. Refresh the page and see if that's what you had in mind. Yes, this is what I had in mind. Grüße, Sven. -- Sigmentation fault. Core dumped.
