On 03/04/2014 17:35, Canek Peláez Valdés wrote: > On Thu, Apr 3, 2014 at 7:25 AM, Douglas J Hunley <[email protected]> > wrote: >> I'm sure this is way more trivial than I'm making it out to be, but how in >> the world would one converty /etc/init.d/dmesg to a systemd service file? > > Mmmh. Seeing [1], I really don't think that's a *service*. It's the > kind of abuse that SysV scripts usually fall into. > > What do you want to accomplish? Less output in the console when > booting with systemd? Then you can set the quiet *kernel* command > line. If you want systemd to be more (or less) verbose, then you can > pass it different arguments in the kernel command line; see [2]. > >> Is there a good online pointer about building service files? > > The guide in [3] is a start; but I don't think it will help you, since > /etc/init.d/dmesg is not a service. Is a hack to control console > output behavior jammed into the init system because why not. > > Regards. > > [1] > http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=blob;f=init.d/dmesg.in;h=5b001fca7542ce7e003af30ca49fdf471efd8871;hb=HEAD > [2] > http://www.freedesktop.org/software/systemd/man/systemd.html#Kernel%20Command%20Line > [3] http://0pointer.de/blog/projects/systemd-for-admins-3.html >
Let's be fair to SysV init though. This is not a hack in the true sense of the word as SysV doesn't impose the concept of a "service" as such. It's more of a $DO_STUFF_HERE concept, as in: - start pid 1 - read /etc/inittab - DO_STUFF_HERE (determined by /etc/rc.d/*) - run login on consoles SysV init pays no attention to what the various STUFF might be so they can correctly be anything and are considered to be unmanaged. Systemd is an effort to categorize things, and to get them consistent, manageable and *managed*. As such, dmesg indeed does not belong with services, but somewhere else. -- Alan McKinnon [email protected]
