I'm trying to execute a test in different Linux server distros (Fedora, Ubuntu, Centos, etc).

I know that there is an init system that can allow programs execution after boot (without login). The problem is that I don't want to have a special case for every different init system between distros. Is there a way to allow root auto login after boot?

By doing this I can have the same shell script for any distro. Or is there a way to workaround this issue?

  • 2
    Why are you doing this? It's generally a very bad idea, and it would help to have context. – gparent Oct 9 '15 at 17:15
  • 2
    As gparent said: Don't do this. – David W Oct 9 '15 at 17:17
  • I have a program that needs to be tested physically on different Linux distros to report performance. – gbriones.gdl Oct 9 '15 at 17:18
  • @gparent: you can't just blanket say "don't do this" without knowing context. there certainly can be valid reasons for it. – Michael Martinez Oct 9 '15 at 22:24
  • @MichaelMartinez You meant to reply to David W there – gparent Oct 11 '15 at 21:59
up vote 1 down vote accepted

I know that there is an init system that can allow programs execution after boot (without login).

Unfortunately these days there is not one init system there is a half dozen popular init systems. For example sysv init, systemd, upstart, etc.

Anyway, if you really want a system to provide you with a console that has root access, you would probably want to update your init system.

I do this for a serial port on a couple of my systems. I have have two very different configurations and I am only using Debian with two different releases. I can't imagine that you will be able to come up with a single method that will apply across all distros. There is just no consistency for how things get started. Systemd should be pretty similar across distros, but it isn't broadly accepted yet.

Debian with sysv init (wheezy) drop to root on serial port

# /etc/inittab
...
# serial port getty spawns sulogin, which drops to a root shell
# on debian if root has a disabled password
T0:23:respawn:/sbin/getty -n -l /sbin/sulogin -L ttyS0 57600 vt102
...

Debian with systemd (jessie) drop to root on serial port

#/etc/systemd/system/getty.target.wants/serial-getty@ttyS1.service
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Serial Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
BindsTo=dev-%i.device
After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service
After=rc-local.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

[Service]
ExecStart=-/sbin/agetty -n -l /sbin/sulogin --keep-baud 115200,38400,9600 %I $TERM
Type=idle
Restart=always
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

[Install]
WantedBy=getty.target

Your best bet might be to give up on the idea of logging in as root, and instead use a configuration management tool like puppet or that can abstract away some various distro-release differences for you. Have that tool trigger your test runs.

  • My fedora says that /etc/inittab is no longer used. Does this mean that it won't work or that it's just deprecated – gbriones.gdl Oct 9 '15 at 19:23
  • I am pretty Centos/Fedora has gone to the SystemD way of doing things for their newest releases. I think Ubuntu is mostly still upstart, Debian tries to have it both ways. – Zoredache Oct 9 '15 at 19:25
  • Actually, Debian doesn't really try to have it both ways; up to and including Wheezy, sysvinit is the default (with systemd offered as an alternative on newer versions); from Jessie onwards, systemd is the default, with sysvinit as the "unsupported but should mostly work, but don't blame us if it breaks" alternative. – a CVn Oct 9 '15 at 20:13

you added a comment: "I have a program that needs to be tested physically on different Linux distros to report performance"

in this case, you might want to consider using docker, that way you dont really need a full os or anything...but if your program for some reason needs to be run on a physical instance, you might want check out some job execution environment like jenkins

  • I'm afraid that docker uses virtualization – gbriones.gdl Oct 28 '15 at 22:34

If it is a command line programming a better approach would be to execute it through SSH. Furthermore you can use SSH keys to login without passwords.

  • SSH autologin as root using an unprotected key sounds like a Bad Idea for any system you care about at all. – a CVn Oct 9 '15 at 20:15
  • yes this would be much worse than the console auto login as root that the OP is talking about. – Michael Martinez Oct 9 '15 at 22:26
  • You can (and you should) protect your private key with a passphrase and then using ssh-agent to auto login – kazantzakis Oct 10 '15 at 16:57

I'm confused about what you want, however if you want to run something as root after boot on Linux, stick it in here on most distros:

/etc/rc.local

Or sometimes

/etc/rc.d/rc.local
  • Does this also work in Ubuntu? – gbriones.gdl Oct 9 '15 at 19:06
  • Yes, I just verified that /etc/rc.local was correct on my Ubuntu and Debian systems. – Ryan Babchishin Oct 9 '15 at 19:07
  • I recall that SUSE keeps it somewhere weird. I had difficulty with that a long time ago. I think Redhat/CentOS/Fedora are like Ubuntu. – Ryan Babchishin Oct 9 '15 at 19:10
  • Is rc.local executed at the end of last runlevel? my program requires some services to start up previously. – gbriones.gdl Oct 9 '15 at 19:56
  • @gbriones.gdl rc.local is usually executed at the very end of the boot process, just before spawning the login getty on the boot console. You would however need to verify that on each specific system to be 100% certain. – a CVn Oct 9 '15 at 20:14

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.