6:11 a.m.
Hi,
My suggestion is that you keep both init systems, SysV/LSB and systemd,
as separate offerings out of many, and forever so.
You would install them as suitable for your individual system needs.
The SysV/LSB system init would be default as is now.
The reason for it is twofold:
- SysV/LSB init system
- it is established, with a long history of familiarity within UNIX/Linux
OS environments, whether by a professional or amateur sysadmin, a system
programmer or architect, a technical or casual user
- adherence to UNIX principles
- ease of use due to shell scripting
- transparency of code due to shell use
- ease of system setup
- ease of prototyping, editing, experimenting, etc
- based on the above, it has a distincit advantage over systemd
- systemd
- as of today, it does not offer any functional advantage over SysV/LSB,
except a new make-up with heavy use of lipstic in form of unit
configuration files (and control functions)
- there is no promised land of "parallelization" and speed, which can not
be achieved without applying concurrency and all system programming
models and tools available today (client-server/master-slave, sockets,
multithreading, synchronization constructs, synchronous/asynchronous
programming, or even hybrid event- and threads-driven programming where
appropriate, etc)
- the project, to achieve full benefits of concurrency, should become fully
autonomous and self-contained
- it should abandon any utilization of or allowing shell processing
(internally or externally)
- it should use coding in C exclusively, with a separate execution
environment, data structures, config files, services definition and
execution, controls, secure programming, etc.
- advantages:
- a separate development env
- speed
- clearer paths to utilization
- availability and possible customization for and in devices or systems
that would have unique requirements, where traditional (script based)
init systems would be impossible or inappropriate
- ability to tailor it for cooperation with other environments (GNOME, etc)
JB
ZZTop
http://www.youtube.com/watch?v=p-y33Uq6HGs
7:58 a.m.
JB wrote:
Hi,
My suggestion is that you keep both init systems, SysV/LSB and systemd,
as separate offerings out of many, and forever so.
+1, but it seems impossible now.
If you prefer to continue with SysV, it is your right to create a fork,
or just an additional repository (starting from F14 code base) with
traditional SysV init system and hundreds of (now removed) traditional
init scripts for hundreds of daemons.
BTW, such a task looks quite realistic (even for two, three persons).
Just trace the main Fedora packages and make needed changes for your
SysV init system and your collection of SysV initrd scripts. I'm sure
you will find adherens in this idea.
The continuation of this discussion here is not productive, anyway.
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy
8:24 a.m.
On Tue, Jul 19, 2011 at 1:11 PM, JB <jb.1234abcd(a)gmail.com> wrote:
Hi,
My suggestion is that you keep both init systems, SysV/LSB and systemd,
as separate offerings out of many, and forever so.
That's just adds a maintenance burden for no real benefit.
You would install them as suitable for your individual system needs.
The SysV/LSB system init would be default as is now.
We should support sysVinit scripts when they are present but we should
not ship them where we have proper unit files
and sure not use them by default. (legacy technology is for backward
compact not more and not less).
8:34 a.m.
On 07/19/2011 11:11 AM, JB wrote:
Hi,
My suggestion is that you keep both init systems, SysV/LSB and systemd,
as separate offerings out of many, and forever so.
You would install them as suitable for your individual system needs.
The SysV/LSB system init would be default as is now.
First of all systemd is the default init systemd and has been from F15
Secondly I'm pretty sure the legacy sysv init system maintainer is happy
to give you the ownership of the component then you can maintain it for
as long as you want...
You probably want to add your self as as co-maintainer to several
components and start reverting code bases and packaging several
components separately you know for the once that have gone the full
systemd route and for the once that have decided to drop the legacy sysv
init support and the legacy sysv init script with it...
You probably need a separate crew to do QA on the legacy sysv init
systemd since I'm pretty sure that QA wants to only be overseeing and
dedicating resource to support one init system and doing that well and
that init systemd being the default one what ever that might be at any
given time.
For the rest of the items you listed in your post it's better that you
list facts/test cases and what not basically everything else but a list
of buzzwords and encase you are going to respond with the "sysadmin
argument" then let me respond to that forehand in reality any competent
sysadmin will adapt to the new init system as he does for various other
code changes in the application stack that runs on the hardware he's
administrating if he doesn't then I suggest you fire him and hire
another one that can.
Now if you just happen to be a sysadmin then I suggest you either get
with the program or expect to be out of job tomorrow since there is
plethora of competent sysadmins out there that are able and willing and
after your job...
If for what ever reason it just happens to be that you find any joy in
maintaining init system(s) then might I suggest the Debian project since
they might end up carrying three.
Thanks
JBG
https://fedoraproject.org/wiki/PackageMaintainers/Join
8:37 a.m.
On Tue, 2011-07-19 at 13:34 +0000, "Jóhann B. Guðmundsson" wrote:
Now if you just happen to be a sysadmin then I suggest you either get
with the program or expect to be out of job tomorrow since there is
plethora of competent sysadmins out there that are able and willing and
after your job...
That remark is neither necessary nor in keeping with fedora's community
standards. Please stop.
-sv
9:37 a.m.
On 07/19/2011 09:37 AM, seth vidal wrote:
On Tue, 2011-07-19 at 13:34 +0000, "Jóhann B. Guðmundsson"
wrote:
> Now if you just happen to be a sysadmin then I suggest you either get
> with the program or expect to be out of job tomorrow since there is
> plethora of competent sysadmins out there that are able and willing and
> after your job...
That remark is neither necessary nor in keeping with fedora's community
standards. Please stop.
+1
steved.
9:01 a.m.
On Tue, 2011-07-19 at 09:57 -0400, Adam Jackson wrote:
On Tue, 2011-07-19 at 11:11 +0000, JB wrote:
> My suggestion is that you keep both init systems, SysV/LSB and systemd,
> as separate offerings out of many, and forever so.
We'll take that under advisement.
Ajax,
That remark is also unnecessary and just comes across as snarky. The
only thing this will achieve is to keep other people from being willing
to comment on issues in the future.
Please stop this.
-sv
11:16 a.m.
seth vidal (skvidal(a)fedoraproject.org) said:
> > My suggestion is that you keep both init systems, SysV/LSB
and systemd,
> > as separate offerings out of many, and forever so.
>
> We'll take that under advisement.
Ajax,
That remark is also unnecessary and just comes across as snarky. The
only thing this will achieve is to keep other people from being willing
to comment on issues in the future.
So, the preference is to say nothing at all?
Bill
11:33 a.m.
On Tue, 2011-07-19 at 12:16 -0400, Bill Nottingham wrote:
seth vidal (skvidal(a)fedoraproject.org) said:
> > > My suggestion is that you keep both init systems, SysV/LSB and systemd,
> > > as separate offerings out of many, and forever so.
> >
> > We'll take that under advisement.
>
> Ajax,
> That remark is also unnecessary and just comes across as snarky. The
> only thing this will achieve is to keep other people from being willing
> to comment on issues in the future.
So, the preference is to say nothing at all?
In lieu of a snarky/derisive comment, yes, that's correct.
-sv
12:04 p.m.
On Tue, 2011-07-19 at 12:16 -0400, Bill Nottingham wrote:
seth vidal (skvidal(a)fedoraproject.org) said:
> > > My suggestion is that you keep both init systems, SysV/LSB and systemd,
> > > as separate offerings out of many, and forever so.
> >
> > We'll take that under advisement.
>
> Ajax,
> That remark is also unnecessary and just comes across as snarky. The
> only thing this will achieve is to keep other people from being willing
> to comment on issues in the future.
So, the preference is to say nothing at all?
I'd suggest something along the lines of 'sorry, but maintaining two
officially-supported init systems side-by-side is an excessive burden on
package maintainers and quality assurance, so we won't be doing it'.
It's hard to go wrong by just politely saying what you mean.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw
http://www.happyassassin.net
12:53 p.m.
On Tue, Jul 19, 2011 at 1:04 PM, Adam Williamson <awilliam(a)redhat.com>wrote:
On Tue, 2011-07-19 at 12:16 -0400, Bill Nottingham wrote:
> seth vidal (skvidal(a)fedoraproject.org) said:
> > > > My suggestion is that you keep both init systems, SysV/LSB and
systemd,
> > > > as separate offerings out of many, and forever so.
> > >
> > > We'll take that under advisement.
> >
> > Ajax,
> > That remark is also unnecessary and just comes across as snarky. The
> > only thing this will achieve is to keep other people from being willing
> > to comment on issues in the future.
>
> So, the preference is to say nothing at all?
I'd suggest something along the lines of 'sorry, but maintaining two
officially-supported init systems side-by-side is an excessive burden on
package maintainers and quality assurance, so we won't be doing it'.
It's hard to go wrong by just politely saying what you mean.
But as someone who is maintaining his own package...
Won't I have to maintain two different init system support files
for both systemd based distros and "all the other Linux and Unix distros"
I also run on?
1:01 p.m.
On Tue, Jul 19, 2011 at 7:53 PM, Fulko Hew <fulko.hew(a)gmail.com> wrote:
But as someone who is maintaining his own package...
Won't I have to maintain two different init system support files
for both systemd based distros and "all the other Linux and Unix distros"
I also run on?
Perhaps three, at least for some time: Traditional SysV, SysV as
implemented by systemd, systemd.
Mirek
1:45 p.m.
Miloslav Trmač (mitr(a)volny.cz) said:
On Tue, Jul 19, 2011 at 7:53 PM, Fulko Hew
<fulko.hew(a)gmail.com> wrote:
> But as someone who is maintaining his own package...
>
> Won't I have to maintain two different init system support files
> for both systemd based distros and "all the other Linux and Unix distros"
> I also run on?
Perhaps three, at least for some time: Traditional SysV, SysV as
implemented by systemd, systemd.
The point is, of course, to not need that second one.
Bill
10:51 a.m.
On Tue, 2011-07-19 at 13:53 -0400, Fulko Hew wrote:
I'd suggest something along the lines of 'sorry, but
maintaining two
officially-supported init systems side-by-side is an excessive
burden on
package maintainers and quality assurance, so we won't be
doing it'.
It's hard to go wrong by just politely saying what you mean.
But as someone who is maintaining his own package...
Won't I have to maintain two different init system support files
for both systemd based distros and "all the other Linux and Unix
distros"
I also run on?
Well, yes. But when I say 'maintainer' I'm talking about Fedora project
package maintainers, not upstream developers.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw
http://www.happyassassin.net
9:36 a.m.
Adam Jackson <ajax <at> redhat.com> writes:
On Tue, 2011-07-19 at 11:11 +0000, JB wrote:
> My suggestion is that you keep both init systems, SysV/LSB and systemd,
> as separate offerings out of many, and forever so.
We'll take that under advisement.
- ajax
I am actually not discouraged.
The current state of systemd is "neither here nor there", and will never be
"there" as designed now, from the conceptual and technical point of view.
They have learned some stuff during these discussions here that clarified
the project's goals as they were and should be.
I think they know it - they are good system programmers.
There is nothing wrong with taking a breather, reflecting, and making a second
approach. In particular, if their testing platform is Fedora and they can
easily turn around now, without any problems.
In my eyes that would be a sign of maturity on their part.
We would give the systemd people a chance to do it right, big way !
They would have a great opportunity to show their talent in full by utilizing
all that UNIX/Linux offers in system programming models and tools.
JB
11:45 a.m.
Just because shell scripts are familiar doesn't make then easier.
Shell scripts can be quite quite fragile. Collectively as admins
we've grown very attuned to dealing with shell semantics good and bad.
None of us who are deeply familiar with shell can You easily assess
the relative merits of systemd because we aren't familiar with systemd
yet.
I've heard the same arguments from other people in other contexts for
years, especially in scientific computing. Why on earth should anyone
ever need to learn anything except IDL scripting for scentific data
analysis. It was good enough 20 years ago..its good enough now. We
have all this complex fragile IDL scripting codebase built up. Why on
earth would be through it a way for html5 based data plotting?
I'm utterly unmoved by any arguments which boil down to "I'm familiar
with this 20+ year old tech, and I don't want to learn something new"
Familiar is not automatically easier or better, harder or worse. It is
simply familiar and the longer we hold on to the familiar the harder
it will every be for us to take the time to invest in better
technologies so we can realize the full potential of those
technologies
-jef
11:51 a.m.
On Tue, 2011-07-19 at 08:45 -0800, Jeff Spaleta wrote:
Just because shell scripts are familiar doesn't make then
easier.
Shell scripts can be quite quite fragile. Collectively as admins
we've grown very attuned to dealing with shell semantics good and bad.
None of us who are deeply familiar with shell can You easily assess
the relative merits of systemd because we aren't familiar with systemd
yet.
I've heard the same arguments from other people in other contexts for
years, especially in scientific computing. Why on earth should anyone
ever need to learn anything except IDL scripting for scentific data
analysis. It was good enough 20 years ago..its good enough now. We
have all this complex fragile IDL scripting codebase built up. Why on
earth would be through it a way for html5 based data plotting?
I'm utterly unmoved by any arguments which boil down to "I'm familiar
with this 20+ year old tech, and I don't want to learn something new"
Familiar is not automatically easier or better, harder or worse. It is
simply familiar and the longer we hold on to the familiar the harder
it will every be for us to take the time to invest in better
technologies so we can realize the full potential of those
technologies
I agree with one section of your argument:
arguments which are just "I'm not used to this" are bad arguments.
Many of the arguments presented in this and other threads do not boil
down to that. If you believe them to do so, Jeff, then you're presenting
a straw man as I'm sure you're aware.
Many of the arguments are this: All change has a cost.
That cost is offset by the benefit of the new feature functionality. If
you introduce change with relatively low introduction cost then you
don't need much benefit to justify it. If you introduce change with a
relatively high introduction cost then the benefits better be
significant to justify it.
This isn't about familiarity, it is simple economics.
-sv
12:48 p.m.
On Tue, Jul 19, 2011 at 8:51 AM, seth vidal <skvidal(a)fedoraproject.org> wrote:
I agree with one section of your argument:
arguments which are just "I'm not used to this" are bad arguments.
Many of the arguments presented in this and other threads do not boil
down to that. If you believe them to do so, Jeff, then you're presenting
a straw man as I'm sure you're aware.
I disagree this thread specifically boils down to familiarity
argument. Shall I break down the original post point by point?
- it is established, with a long history of familiarity within UNIX/Linux
OS environments, whether by a professional or amateur sysadmin, a system
programmer or architect, a technical or casual user
straight up familiarity argument
- adherence to UNIX principles
which principles exactly? I don't recognize which principle a reliance
on shell soup is a Unix principle of merit. I will say that I believe
that systemd tries to take a step closer to the principle of
clean simple interface than the complexity of the layered shell
centric init we've built over the years.
- ease of use due to shell scripting
straight up familiarty argument.
- transparency of code due to shell use
how is shell more transparent? from my meager understanding of
systemd we are actually getting better more systematic failure and
logging information from systemd unit files than we get from the
complexity of shell scripts. Are we not?
- ease of system setup
straight up familiarity argument. shell based is only easier because
we are familiar with shell and its semantics.
- ease of prototyping, editing, experimenting, etc
straight up familarity argument. How is systemd harder to prototype
with other than the fact we collectively aren't familiar with it yet?
Many of the arguments are this: All change has a cost.
I'm not denying that change has no cost. But upkeep has a cost as
well. Just because my father-in-law can keep his 40+ year old snow
blower operationally tweaking it doesn't mean its the most valuable
use of his time compared to buying a newer one and learning how to
maintain the newer design. Then again his stated mission in life
isn't to innovate snow blower design and be on the cutting edge of
snow removal.
-jef
12:59 p.m.
On Tue, Jul 19, 2011 at 1:48 PM, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On Tue, Jul 19, 2011 at 8:51 AM, seth vidal
<skvidal(a)fedoraproject.org>
wrote:
> I agree with one section of your argument:
> arguments which are just "I'm not used to this" are bad arguments.
>
> Many of the arguments presented in this and other threads do not boil
> down to that. If you believe them to do so, Jeff, then you're presenting
> a straw man as I'm sure you're aware.
I disagree this thread specifically boils down to familiarity
argument. Shall I break down the original post point by point?
... snip ...
- transparency of code due to shell use
how is shell more transparent? from my meager understanding of
systemd we are actually getting better more systematic failure and
logging information from systemd unit files than we get from the
complexity of shell scripts. Are we not?
Up until now, my package is architecture independent.
From what I understand, I will now have to provide some systemd
application that is coded in C?
If that is the case, I now have to create an RPM per-architecture
and loose my architecture independence.
True or false?
1:23 p.m.
On Tue, Jul 19, 2011 at 9:59 AM, Fulko Hew <fulko.hew(a)gmail.com> wrote:
From what I understand, I will now have to provide some systemd
application that is coded in C?
If that is the case, I now have to create an RPM per-architecture
and loose my architecture independence.
I do not believe you can have to incorporate any C code, even if you
want to use the optional socket activation. There is a reference
function written in C for socket activation but its not strictly
required. It can be reimplemented natively in any interpreted
programming language if needed.
Salient references for the socket activation feature:
Notes section here:
http://0pointer.de/public/systemd-man/sd_listen_fds.html
Short discussion on what it would take to re-implement in python native:
http://lists.freedesktop.org/archives/systemd-devel/2010-November/000722....
-jef
1:30 p.m.
On 07/19/2011 05:59 PM, Fulko Hew wrote:
On Tue, Jul 19, 2011 at 1:48 PM, Jeff Spaleta <jspaleta(a)gmail.com
<mailto:jspaleta@gmail.com>> wrote:
On Tue, Jul 19, 2011 at 8:51 AM, seth vidal
<skvidal(a)fedoraproject.org <mailto:skvidal@fedoraproject.org>> wrote:
> I agree with one section of your argument:
> arguments which are just "I'm not used to this" are bad
arguments.
>
> Many of the arguments presented in this and other threads do
not boil
> down to that. If you believe them to do so, Jeff, then you're
presenting
> a straw man as I'm sure you're aware.
I disagree this thread specifically boils down to familiarity
argument. Shall I break down the original post point by point?
... snip ...
- transparency of code due to shell use
how is shell more transparent? from my meager understanding of
systemd we are actually getting better more systematic failure and
logging information from systemd unit files than we get from the
complexity of shell scripts. Are we not?
Up until now, my package is architecture independent.
From what I understand, I will now have to provide some systemd
application that is coded in C?
If that is the case, I now have to create an RPM per-architecture
and loose my architecture independence.
True or false?
False
Hum best is to provide you with example which daemon do you maintain I
can convert it for you and provide it to you as an example anyway here's
an example of a systemd unit that I converted sometime ago for a know
application named tomcat6 and I'll leave readers to be the judge of that
what is harder to understand the native systemd unit or the legacy sysv
init script...
First the converted unit file
# cat /lib/systemd/system/tomcat6.service
[Unit]
Description=Apache Tomcat Web Applications Server
After=systlog.target network.target
[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/tomcat6
ExecStart=/usr/sbin/tomcat6 start
ExecStop=/usr/sbin/tomcat6 stop
[Install]
WantedBy=multi-user.target
Now the legacy sysv init script that everybody seem to love and cheerish
so much...
# cat /etc/rc.d/init.d/tomcat6
#!/bin/bash
#
# tomcat6 This shell script takes care of starting and stopping Tomcat
#
# chkconfig: - 80 20
#
### BEGIN INIT INFO
# Provides: tomcat6
# Required-Start: $network $syslog
# Required-Stop: $network $syslog
# Default-Start:
# Default-Stop:
# Description: Release implementation for Servlet 2.5 and JSP 2.1
# Short-Description: start and stop tomcat
### END INIT INFO
#
# - originally written by Henri Gomez, Keith Irwin, and Nicolas Mailhot
# - heavily rewritten by Deepak Bhole and Jason Corley
#
## Source function library.
#. /etc/rc.d/init.d/functions
# Source LSB function library.
if [ -r /lib/lsb/init-functions ]; then
. /lib/lsb/init-functions
else
exit 1
fi
DISTRIB_ID=`lsb_release -i -s 2>/dev/null`
NAME="$(basename $0)"
unset ISBOOT
if [ "${NAME:0:1}" = "S" -o "${NAME:0:1}" = "K" ];
then
NAME="${NAME:3}"
ISBOOT="1"
fi
# For SELinux we need to use 'runuser' not 'su'
if [ -x "/sbin/runuser" ]; then
SU="/sbin/runuser -s /bin/sh"
else
SU="/bin/su -s /bin/sh"
fi
# Get the tomcat config (use this for environment specific settings)
TOMCAT_CFG="/etc/tomcat6/tomcat6.conf"
if [ -r "$TOMCAT_CFG" ]; then
. $TOMCAT_CFG
fi
# Get instance specific config file
if [ -r "/etc/sysconfig/${NAME}" ]; then
. /etc/sysconfig/${NAME}
fi
# Define which connector port to use
CONNECTOR_PORT="${CONNECTOR_PORT:-8080}"
# Path to the tomcat launch script
TOMCAT_SCRIPT="/usr/sbin/tomcat6"
# Tomcat program name
TOMCAT_PROG="${NAME}"
# Define the tomcat username
TOMCAT_USER="${TOMCAT_USER:-tomcat}"
# Define the tomcat log file
TOMCAT_LOG="${TOMCAT_LOG:-${CATALINA_HOME}/logs/catalina.out}"
RETVAL="0"
# Look for open ports, as the function name might imply
function findFreePorts() {
local isSet1="false"
local isSet2="false"
local isSet3="false"
local lower="8000"
randomPort1="0"
randomPort2="0"
randomPort3="0"
local -a listeners="( $(
netstat -ntl | \
awk '/^tcp/ {gsub("(.)*:", "", $4); print
$4}'
) )"
while [ "$isSet1" = "false" ] || \
[ "$isSet2" = "false" ] || \
[ "$isSet3" = "false" ]; do
let port="${lower}+${RANDOM:0:4}"
if [ -z `expr " ${listeners[*]} " : ".*\( $port \).*"` ];
then
if [ "$isSet1" = "false" ]; then
export randomPort1="$port"
isSet1="true"
elif [ "$isSet2" = "false" ]; then
export randomPort2="$port"
isSet2="true"
elif [ "$isSet3" = "false" ]; then
export randomPort3="$port"
isSet3="true"
fi
fi
done
}
function makeHomeDir() {
if [ ! -d "$CATALINA_HOME" ]; then
echo "$CATALINA_HOME does not exist, creating"
if [ ! -d "/usr/share/${NAME}" ]; then
mkdir /usr/share/${NAME}
cp -pLR /usr/share/tomcat6/* /usr/share/${NAME}
fi
mkdir -p /var/log/${NAME} \
/var/cache/${NAME} \
/var/tmp/${NAME}
ln -fs /var/cache/${NAME} ${CATALINA_HOME}/work
ln -fs /var/tmp/${NAME} ${CATALINA_HOME}/temp
cp -pLR /usr/share/${NAME}/bin $CATALINA_HOME
cp -pLR /usr/share/${NAME}/conf $CATALINA_HOME
ln -fs /usr/share/java/tomcat6 ${CATALINA_HOME}/lib
ln -fs /usr/share/tomcat6/webapps ${CATALINA_HOME}/webapps
chown ${TOMCAT_USER}:${TOMCAT_USER} /var/log/${NAME}
fi
}
function parseOptions() {
options=""
options="$options $(
awk '!/^#/ && !/^$/ { ORS=" "; print "export
", $0,
";" }' \
$TOMCAT_CFG
)"
if [ -r "/etc/sysconfig/${NAME}" ]; then
options="$options $(
awk '!/^#/ && !/^$/ { ORS=" ";
print "export ", $0, ";"
}' \
/etc/sysconfig/${NAME}
)"
fi
TOMCAT_SCRIPT="$options ${TOMCAT_SCRIPT}"
}
# See how we were called.
function start() {
echo -n "Starting ${TOMCAT_PROG}: "
if [ "$RETVAL" != "0" ]; then
log_failure_msg
return
fi
if [ -f "/var/lock/subsys/${NAME}" ]; then
if [ -f "/var/run/${NAME}.pid" ]; then
read kpid < /var/run/${NAME}.pid
# if checkpid $kpid 2>&1; then
if [ -d "/proc/${kpid}" ]; then
log_success_msg
if [ "$DISTRIB_ID" = "MandrivaLinux" ]; then
echo
fi
return 0
fi
fi
fi
# fix permissions on the log and pid files
export CATALINA_PID="/var/run/${NAME}.pid"
touch $CATALINA_PID 2>&1 || RETVAL="4"
if [ "$RETVAL" -eq "0" -a "$?" -eq "0" ];
then
chown ${TOMCAT_USER}:${TOMCAT_USER} $CATALINA_PID
fi
[ "$RETVAL" -eq "0" ] && touch $TOMCAT_LOG 2>&1 ||
RETVAL="4"
if [ "$RETVAL" -eq "0" -a "$?" -eq "0" ];
then
chown ${TOMCAT_USER}:${TOMCAT_USER} $TOMCAT_LOG
fi
if [ "$CATALINA_HOME" != "/usr/share/tomcat6" -a
"$RETVAL" -eq "0"
]; then
# Create a tomcat directory if it doesn't exist
makeHomeDir
# If CATALINA_HOME doesn't exist modify port number so that
# multiple instances don't interfere with each other
findFreePorts
sed -i -e "s/8005/${randomPort1}/g" -e
"s/8080/${CONNECTOR_PORT}/g" \
-e "s/8009/${randomPort2}/g" -e "s/8443/${randomPort3}/g"
\
${CATALINA_HOME}/conf/server.xml
fi
parseOptions
if [ "$RETVAL" -eq "0" -a "$SECURITY_MANAGER" =
"true" ]; then
$SU - $TOMCAT_USER -c "${TOMCAT_SCRIPT} start-security" \
> ${CATALINA_HOME}/logs/initd.log 2>&1 ||
RETVAL="4"
else
[ "$RETVAL" -eq "0" ] && $SU - $TOMCAT_USER -c
"${TOMCAT_SCRIPT}
start"> ${CATALINA_HOME}/logs/initd.log
2>&1 || RETVAL="4"
fi
if [ "$RETVAL" -eq "0" ]; then
log_success_msg
touch /var/lock/subsys/${NAME}
else
log_failure_msg "Error code ${RETVAL}"
fi
if [ "$DISTRIB_ID" = "MandrivaLinux" ]; then
echo
fi
}
function stop() {
echo -n "Stopping ${TOMCAT_PROG}: "
if [ -f "/var/lock/subsys/${NAME}" ]; then
parseOptions
if [ "$RETVAL" -eq "0" ]; then
touch /var/lock/subsys/${NAME} 2>&1 || RETVAL="4"
[ "$RETVAL" -eq "0" ] && $SU - $TOMCAT_USER -c
"${TOMCAT_SCRIPT} stop" >> ${CATALINA_HOME}/logs/initd.log 2>&1 ||
RETVAL="4"
fi
if [ "$RETVAL" -eq "0" ]; then
count="0"
if [ -f "/var/run/${NAME}.pid" ]; then
read kpid < /var/run/${NAME}.pid
until [ "$(ps --pid $kpid | grep -c $kpid)" -eq "0" ] ||
\
[ "$count" -gt "$SHUTDOWN_WAIT" ]; do
if [ "$SHUTDOWN_VERBOSE" = "true" ]; then
echo "waiting for processes $kpid to exit"
fi
sleep 1
let count="${count}+1"
done
if [ "$count" -gt "$SHUTDOWN_WAIT" ]; then
if [ "$SHUTDOWN_VERBOSE" = "true" ]; then
log_warning_msg "killing processes which did
not stop after ${SHUTDOWN_WAIT} seconds"
fi
kill -9 $kpid
fi
log_success_msg
fi
rm -f /var/lock/subsys/${NAME} /var/run/${NAME}.pid
else
log_failure_msg
RETVAL="4"
fi
else
log_success_msg
RETVAL="0"
fi
if [ "$DISTRIB_ID" = "MandrivaLinux" ]; then
echo
fi
}
function usage()
{
echo "Usage: $0
{start|stop|restart|condrestart|try-restart|reload|force-reload|status|version}"
RETVAL="2"
}
# See how we were called.
RETVAL="0"
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
condrestart|try-restart)
if [ -f "/var/run/${NAME}.pid" ]; then
stop
start
fi
;;
reload)
RETVAL="3"
;;
force-reload)
if [ -f "/var/run/${NAME}.pid" ]; then
stop
start
fi
;;
status)
if [ -f "/var/run/${NAME}.pid" ]; then
read kpid < /var/run/${NAME}.pid
if [ -d "/proc/${kpid}" ]; then
log_success_msg "${NAME} (pid ${kpid}) is running..."
RETVAL="0"
else
# The pid file exists but the process is not running
log_warning_msg "PID file exists, but process is not
running"
RETVAL="1"
fi
else
pid="$(/usr/bin/pgrep -d , -u ${TOMCAT_USER} -G
${TOMCAT_USER} java)"
if [ -z "$pid" ]; then
# status ${NAME}
# RETVAL="$?"
log_success_msg "${NAME} is stopped"
RETVAL="3"
else
log_success_msg "${NAME} (pid $pid) is running..."
RETVAL="0"
fi
fi
if [ -f /var/lock/subsys/${NAME} ]; then
pid="$(/usr/bin/pgrep -d , -u ${TOMCAT_USER} -G
${TOMCAT_USER} java)"
# The lockfile exists but the process is not running
if [ -z "$pid" ]; then
log_failure_msg "${NAME} lockfile exists but process is
not running"
RETVAL="2"
fi
fi
;;
version)
${TOMCAT_SCRIPT} version
;;
*)
usage
;;
esac
exit $RETVAL
1:43 p.m.
2011/7/19 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>:
Hum best is to provide you with example which daemon do you maintain
I can
convert it for you and provide it to you as an example anyway here's an
example of a systemd unit that I converted sometime ago for a know
application named tomcat6 and I'll leave readers to be the judge of that
what is harder to understand the native systemd unit or the legacy sysv init
script...
[snip for brevity]
What did you do about those specialized functions: findFreePorts
makeHomeDir and parseOptions? Did you move those functions elsewhere?
2:08 p.m.
On 07/19/2011 06:43 PM, Jeff Spaleta wrote:
2011/7/19 "Jóhann B.
Guðmundsson"<johannbg(a)gmail.com>:
> Hum best is to provide you with example which daemon do you maintain I can
> convert it for you and provide it to you as an example anyway here's an
> example of a systemd unit that I converted sometime ago for a know
> application named tomcat6 and I'll leave readers to be the judge of that
> what is harder to understand the native systemd unit or the legacy sysv init
> script...
[snip for brevity]
What did you do about those specialized functions: findFreePorts
makeHomeDir and parseOptions? Did you move those functions elsewhere?
Nope..
This unit file is just laying around in bugzilla as so many of them but
if the maintainers actually need that stuff they would probably throw it
in /usr/sbin/tomcat6 which is where the actual start magic is happening...
JBG
2:51 p.m.
On 22:50:10 Tuesday 19 July 2011 Jóhann B. Guðmundsson wrote:
On 07/19/2011 06:43 PM, Jeff Spaleta wrote:
> 2011/7/19 "Jóhann B. Guðmundsson"<johannbg(a)gmail.com>:
>> Hum best is to provide you with example which daemon do you maintain I
>> can convert it for you and provide it to you as an example anyway
>> here's an example of a systemd unit that I converted sometime ago for a
>> know application named tomcat6 and I'll leave readers to be the judge
>> of that what is harder to understand the native systemd unit or the
>> legacy sysv init script...
>
> [snip for brevity]
>
>
> What did you do about those specialized functions: findFreePorts
> makeHomeDir and parseOptions? Did you move those functions elsewhere?
Nope..
This unit file is just laying around in bugzilla as so many of them but
if the maintainers actually need that stuff they would probably throw it
in /usr/sbin/tomcat6 which is where the actual start magic is happening...
FWIW, tomcat package (note the missing 6) is at version 7.x.y and ships with
the systemd integration and seems to be working fine.
Alexander Kurtakov
JBG
3:23 p.m.
On 07/19/2011 07:51 PM, Alexander Kurtakov wrote:
FWIW, tomcat package (note the missing 6) is at version 7.x.y and
ships with
the systemd integration and seems to be working fine.
Alexander Kurtakov
If you are speaking of this then that fails to meet the packaging
guidelines...
[Unit]
Description=Release implementation for Servlet 3.0 and JSP 2.2
After=syslog.target network.target
[Service]
Type=forking
PIDFile=/var/run/tomcat.pid
EnvironmentFile=/etc/sysconfig/tomcat
ExecStart=/etc/init.d/tomcat start<-- this kinda is a hack and does not meet the
packaing guidelines
ExecStop=/etc/init.d/tomcat stop<-- this kinda is a hack and does not meet the packaing
guidelines
[Install]
WantedBy=multi-user.target
"Packages
may also provide a SysV initscript file, but are not required to do so.
This format is considered legacy, but Fedora still contains init
mechanisms such as upstart which do not support the systemd unit file
format. If present, the SysV initscript(s) must go into an optional
subpackage, so as not to confuse sysadmins. The guidelines for SysV
initscripts can be found here:Packaging:SysVInitScript
<http://fedoraproject.org/wiki/Packaging:SysVInitScript>"
So there is a question if we cant properly convert it..
JBG
Note.png <http://fedoraproject.org/wiki/File:Note.png>
1:49 p.m.
On 07/19/2011 02:30 PM, "Jóhann B. Guðmundsson" wrote:
First the converted unit file
[... 12 lines ...]
Now the legacy sysv init script that everybody seem to love and cheerish
so much...
[...ton of lines ...]
Be fair though---the sysv script does a lot of config: ports, etc. I
agree that systemd is cleaner and the mechanics of controlling the
execution SHOULD be separated from startup config details, those two
examples are not equivalent.
2:06 p.m.
Le mardi 19 juillet 2011 à 18:30 +0000, "Jóhann B. Guðmundsson" a
écrit :
Hum best is to provide you with example which daemon do you maintain
I
can convert it for you and provide it to you as an example anyway here's
an example of a systemd unit that I converted sometime ago for a know
application named tomcat6 and I'll leave readers to be the judge of that
what is harder to understand the native systemd unit or the legacy sysv
init script...
First the converted unit file
Now the legacy sysv init script that everybody seem to love and
cheerish
so much...
I don't think anyone loves this particular sysv script but you realize I
hope that 99% of its complexity is here to make multi-instanciation
trivial (because when every user can run an IDE like eclipse that wants
its own tomcat instance to play with you *do* need multi-instanciation)
and your unit file does not support this use case at all?
--
Nicolas Mailhot
2:31 p.m.
On Tue, 19 Jul 2011 21:06:03 +0200
Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
Le mardi 19 juillet 2011 à 18:30 +0000, "Jóhann B.
Guðmundsson" a
écrit :
> Hum best is to provide you with example which daemon do you
> maintain I can convert it for you and provide it to you as an
> example anyway here's an example of a systemd unit that I converted
> sometime ago for a know application named tomcat6 and I'll leave
> readers to be the judge of that what is harder to understand the
> native systemd unit or the legacy sysv init script...
>
> First the converted unit file
> Now the legacy sysv init script that everybody seem to love and
> cheerish so much...
I don't think anyone loves this particular sysv script but you
realize I hope that 99% of its complexity is here to make
multi-instanciation trivial (because when every user can run an IDE
like eclipse that wants its own tomcat instance to play with you *do*
need multi-instanciation) and your unit file does not support this
use case at all?
I think the question is: why should this particular usecase be covered
by the SYSTEM init script?
In other words, why should the package tomcat6 not provide a
better /usr/bin/tomcat6 "binary" (or shell script, or whatever) that
can work out on its own whether to multi-instantiate?
--Stijn
2:37 p.m.
On Tue, Jul 19, 2011 at 11:31 AM, Stijn Hoop <stijn(a)sandcat.nl> wrote:
In other words, why should the package tomcat6 not provide a
better /usr/bin/tomcat6 "binary" (or shell script, or whatever) that
can work out on its own whether to multi-instantiate?
In this case the executable in question is in fact a bash script that
appears to be a distro-specific enhancement...but an upstream
deliverable.
So it definitely appears as if the distro maintainer for this package
have the leeway to move the functions into the "wrapper" executable
script instead of letting them linger in the init "config"
Why these were put in the initscript instead of the executable wrapper
would seem to be an arbitrary decision allowed only because we've
historically had a very fuzzy boundary between config and execution
logic at the distribution level.
-jef
2:38 p.m.
On Tue, Jul 19, 2011 at 11:37 AM, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
In this case the executable in question is in fact a bash script
that
appears to be a distro-specific enhancement...but an upstream
deliverable.
sorry that should read... but not an upstream delivarble... that _not_
is sort of important in that sentence.
-jef
4:33 p.m.
Le mardi 19 juillet 2011 à 11:37 -0800, Jeff Spaleta a écrit :
On Tue, Jul 19, 2011 at 11:31 AM, Stijn Hoop <stijn(a)sandcat.nl>
wrote:
> In other words, why should the package tomcat6 not provide a
> better /usr/bin/tomcat6 "binary" (or shell script, or whatever) that
> can work out on its own whether to multi-instantiate?
In this case the executable in question is in fact a bash script that
appears to be a distro-specific enhancement...but an upstream
deliverable.
Yes tomcat has several layers of stuff that grew over time and try to
integrate the java code in the system as a normal service (heretical
wish)
So it definitely appears as if the distro maintainer for this
package
have the leeway to move the functions into the "wrapper" executable
script instead of letting them linger in the init "config"
All this code is here just to instanciate the service and do the related
housekeeping. It does not belong in a separate script any more or less
than the rest of the sysv stuff. That example just shows the sysv setup
was flexible enough to handle complex multi-instanciated setups and
systemd so far isn't
--
Nicolas Mailhot
6:12 p.m.
On Tue, Jul 19, 2011 at 1:33 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
All this code is here just to instanciate the service and do the
related
housekeeping. It does not belong in a separate script any more or less
than the rest of the sysv stuff. That example just shows the sysv setup
was flexible enough to handle complex multi-instanciated setups and
systemd so far isn't
It is your opinion that having init scripts potentially create
directories such as /usr/share/tomcat6 as part of boot up and service
initialization is a best practice? And initscripts should prefer to
edit files in /usr/share instead of editting files /var/ ?
because that is some of what the makeHomeDir() function in the tomcat6
initscript does. Is that really something we want to encourage to see
being done as part of initscripts? Really? I can't believe that. In
fact I'm sort of grossed out
by what that tomcat6 initscript potentially does based on conditional
logic. Sure creating directories in tmp or var on boot up I can
see..but creating and edtting directories in /usr/share? And why
isn't it making use of information in /etc/tomcat6 but instead is
popularting from /usr/share/tomcat when recreating missing elements?
I simply don't understand how this is a good thing. This isn't
flexibility to serve a good purpose...this is abuse of a flexible tool
to hide system _brokenness_ from an administrator. There's even some
clearly deprecated logic in there which try to identify boot time runs
of the init versus manual runs with the completely unused ISBOOT, but
since ISBOOT is set but unused I can only guess as to what was
intended in the past.
there's even special casing for Mandriva specifically in that init...awesome.
And I'll reiterate with a little more strength. I've read the wrapper
script in F15 that gets dumped to /usr/sbin/tomcat6. I see absolutely
no reason why the necessary clever random free port locator logic
which allows upto 3. additional connectors could not be placed into
the distro specific wrapper in /usr/bin/ and run conditionally from
systemd based on a cmdline argument that activates the random port
locator logic. Why is 3 hardcoded anyways? Maybe because there are by
default 3 such instances instances in the default server.xml. What
if an admin edits their server.xml under /etc/tomcat6 (which is what I
expect an admin to do) tio added a 4th and 5th connector? This
initscript logic _fails_. The sed construction itself is also
extremely fragile when replacing port numbers and isn't using any sort
of variable substitution (like how yum internally does substitution
$releasevar for example).
And to be quite blunt, the wrapper's argument handling is very very
poor. It takes exactly one argument. It could easily be extended to
allow for multiple cmdline options and get back the same capability
expressed in the initscript port locator logic. I see no reason why
the necessary logic to find an unused port and to do the other
necessary multi-instance configs needs to be split between init. The
logic right now for the random port stuff only seems to fire if
/usr/share/$NAME/ is actually missing and needs to be regenerated.
What a mess
/etc/tomcat6/ exists but not all of the info in there is actually used
/etc/sysconfig/tomcat6 exists... why can't that be put in /etc/tomcat6/ ?
/usr/share/tomcat6/ exists and is being used as a pattern for
multi-instance needs
/usr/share/random_name/ will potentially be created based on the
contents of /etc/sysconfig/random_name if and only if this init
script is copied to a new initscript named random_name
I would not hold up the shell logic here as as best practices.
-jef
4:06 a.m.
Le Mer 20 juillet 2011 01:12, Jeff Spaleta a écrit :
On Tue, Jul 19, 2011 at 1:33 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
> All this code is here just to instanciate the service and do the related
> housekeeping. It does not belong in a separate script any more or less
> than the rest of the sysv stuff. That example just shows the sysv setup
> was flexible enough to handle complex multi-instanciated setups and
> systemd so far isn't
It is your opinion that having init scripts potentially create
directories … is a best practice?
As I said before, I am not particularly fond of that script, it is clearly
fugly and I would not have written it this way (to add to your list I loath
variable port numbers, it makes filtering and selinux hell, people would be
well advised to use a well-defined port on one of the numerous local ips
available instead, and map this port to a virtual ip in netfilter if it
actually needs use outside the box itself).
Nevertheless, there is nothing particularly tomcat specific here, it's mostly
the kind of generic boilerplate one needs to multi-instanciate a service :
1. find free resources not conflicting with another instance (ip, port,
socket, working directory)
2. instanciate them and apply security settings to isolate each instance properly
systemd is advertised as making it possible to get rid of all kinds of generic
shell boilerplate which is being reinvented right and left in sysv scripts.
And replace is with clean streamlined reused C implementations. Well, here is
a (particularly atrocious) example of such boilerplate. Pushing it in
/usr/sbin tomcat is not cleaning it up, it's just hiding it under the carpet.
That's exactly the contrary of systemd stated aims.
I know Fedora has not really pushed multi-instanciation before (but there are
exceptions, see clamav). But our users do need multi-instanciation and
routinely tweak our init scripts for this reason. They won't appreciate
systemd pulling the carpet under their feet. If systemd is to be adopted, it
needs to make it easier to multi-instanciate, not harder.
Not to mention that new constrains like /srv/, selinux, generalized
firewalling, frequent updates make multi-instanciating a lot harder than it
used to be so it could really use some init need to replace all the shell goo
people have to use nowadays
--
Nicolas Mailhot
4:57 a.m.
On 07/20/2011 09:06 AM, Nicolas Mailhot wrote:
Le Mer 20 juillet 2011 01:12, Jeff Spaleta a écrit :
> On Tue, Jul 19, 2011 at 1:33 PM, Nicolas Mailhot
> <nicolas.mailhot(a)laposte.net> wrote:
>> All this code is here just to instanciate the service and do the related
>> housekeeping. It does not belong in a separate script any more or less
>> than the rest of the sysv stuff. That example just shows the sysv setup
>> was flexible enough to handle complex multi-instanciated setups and
>> systemd so far isn't
> It is your opinion that having init scripts potentially create
> directories … is a best practice?
As I said before, I am not particularly fond of that script, it is clearly
fugly and I would not have written it this way (to add to your list I loath
variable port numbers, it makes filtering and selinux hell, people would be
well advised to use a well-defined port on one of the numerous local ips
available instead, and map this port to a virtual ip in netfilter if it
actually needs use outside the box itself).
Nevertheless, there is nothing particularly tomcat specific here, it's mostly
the kind of generic boilerplate one needs to multi-instanciate a service :
1. find free resources not conflicting with another instance (ip, port,
socket, working directory)
2. instanciate them and apply security settings to isolate each instance properly
systemd is advertised as making it possible to get rid of all kinds of generic
shell boilerplate which is being reinvented right and left in sysv scripts.
And replace is with clean streamlined reused C implementations. Well, here is
a (particularly atrocious) example of such boilerplate. Pushing it in
/usr/sbin tomcat is not cleaning it up, it's just hiding it under the carpet.
That's exactly the contrary of systemd stated aims.
I know Fedora has not really pushed multi-instanciation before (but there are
exceptions, see clamav). But our users do need multi-instanciation and
routinely tweak our init scripts for this reason. They won't appreciate
systemd pulling the carpet under their feet. If systemd is to be adopted, it
needs to make it easier to multi-instanciate, not harder.
Not to mention that new constrains like /srv/, selinux, generalized
firewalling, frequent updates make multi-instanciating a lot harder than it
used to be so it could really use some init need to replace all the shell goo
people have to use nowadays
If it's not sufficient for administrators to copy a unit file from
/lib/systemd/system to a new name undir /etc/systemd/system and do the
necessary changes to run another instance of it and reload the systemd
daemon then we have templates which allows creation of multiple units
from a single configuration file.
JBG
6:29 a.m.
Le Mer 20 juillet 2011 11:57, "Jóhann B. Guðmundsson" a écrit :
If it's not sufficient for administrators to copy a unit file
from
/lib/systemd/system to a new name undir /etc/systemd/system and do the
necessary changes to run another instance of it and reload the systemd
daemon then we have templates which allows creation of multiple units
from a single configuration file.
I don't think someone would have written all the 'find a free port, create a
new workdir, etc' logic in the tomcat script if just 'copy and change settings
in the init file' was scaling for his use. After all, 'copy and change
things'
could have been done with the sysv script too, without writing complex shell
helpers.
--
Nicolas Mailhot
12:58 p.m.
On Wed, Jul 20, 2011 at 3:29 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
I don't think someone would have written all the 'find a free
port, create a
new workdir, etc' logic in the tomcat script if just 'copy and change settings
in the init file' was scaling for his use. After all, 'copy and change
things'
could have been done with the sysv script too, without writing complex shell
helpers.
I wouldn't call those complex and I wouldn't say they scale. All it
does is make it possible to replicate the default /usr/share config as
packaged, by automating some copying and some file mangling in a very
fragile way. You walk away from the default config by editting that
server.xml file as a site admin and this approach blows up.
And as a day-to-day writer of shell scripts to get things done, shell
scripts I'd never ever encourage anyone else to rely on or reuse
outside of my tailored environments.. I would have to say that you are
probably making the wrong assumption with regard to motivation and
choice of tools and the amount of time spent thinking about how to
make the multi-instance stuff for tomcat be robust enough to be
generally useful for other people. Just replacing hardcoded port
numbers in the default xml file shows a distinct lack of understanding
how how flexible and thus complex active tomcat6 configurations can
be. The tomcat6 intscript logic seems to go out of its way to ignore
local admin reconfiguration in /etc/tomcat6/ in order to enforce the
assumed default settings from /usr/share/tomcat6 to make the
multi-instance magic work as desired. how is this a good thing? By
putting more flexibility into the shell based init system in the hands
of packagers we now have a situation where a packager's decision
making to be narrowly clever results in ignoring the inherent
configuration flexibility of the actual daemon being initiated.
And even if you do use the default configs, you can't re-instance with
an arbitrary name. Anything starting with an S or a K gets mangled to
try to account for the runlevel symlink naming.
And furthermore since there's no inheritance of logic from the
original tomcat6 initscript that is copied to create to create the
second instance, if the original gets updated via package manager
action to fix logic bugs(and there are logic bugs I assure you) then
your second instance does not inherent the changes. How is this a good
thing?
The tomcat6 intscript multi-instance support is a quick undocumented
and unique hack, nothing more. Just look at how it mangles the
executable basename to try to be clever and figure out which file in
sysconfig to use for settings. Clearly the goal was to try to make it
possible to "just copy and rename" the tomcat6 initscript without the
admin needing to edit anything in the initscript itself and have it
work with a random new named initscript. And you know what that would
be perfectly fine as a site specific hack that an admin cooked up
tailored to their environment. Similar logic could be run as a
pre-exec script in a systemd unit file if an admin really wanted to do
it. But I certainly would not choose to ship it enabled by default
with its current..problems. It doesn't actually work in environments
where the local admin has actually tailored their tomcat6 configs (the
real configs in /etc/tomcat6 not the distro specific sysconfig junk).
Whereas the templating features of systemd unit files are documented
and are standardized for _all_ services to make use of and allow for
inheritance from default unit files and admin overrides of those same
defaults. In fact the systemd templating stuff resolves of the
problems in the initscript hack, the undocumented limitations in the
mangling of the basename.
-jef
8:49 a.m.
On Wed, Jul 20, 2011 at 09:57:13AM +0000, "Jóhann B. Guðmundsson" wrote:
If it's not sufficient for administrators to copy a unit file
from
/lib/systemd/system to a new name undir /etc/systemd/system and do the
necessary changes to run another instance of it and reload the systemd
daemon then we have templates which allows creation of multiple units
from a single configuration file.
This way the copied unit file never gets updated if the original one is
updated, with the old sysv scripts you could do an ln -s foo newfoo
and get the updates.
Kostas
8:53 a.m.
On 07/20/2011 03:49 PM, Kostas Georgiou wrote:
This way the copied unit file never gets updated if the original one
is
updated, with the old sysv scripts you could do an ln -s foo newfoo
and get the updates.
You can use:
.include /the/original/unit/file
and only override the specific options you need.
Michal
10:21 a.m.
On 20/07/11 14:53, Michal Schmidt wrote:
On 07/20/2011 03:49 PM, Kostas Georgiou wrote:
> This way the copied unit file never gets updated if the original one is
> updated, with the old sysv scripts you could do an ln -s foo newfoo
> and get the updates.
You can use:
.include /the/original/unit/file
and only override the specific options you need.
Michal
Where would you place this line?
asked out of ignorance om my part.
--
Regards,
Frank Murphy
UTF_8 Encoded
Friend of fedoraproject.org
11:16 a.m.
On Wed, 20.07.11 16:21, Frank Murphy (frankly3d(a)gmail.com) wrote:
On 20/07/11 14:53, Michal Schmidt wrote:
> On 07/20/2011 03:49 PM, Kostas Georgiou wrote:
>> This way the copied unit file never gets updated if the original one is
>> updated, with the old sysv scripts you could do an ln -s foo newfoo
>> and get the updates.
>
> You can use:
> .include /the/original/unit/file
> and only override the specific options you need.
>
> Michal
Where would you place this line?
asked out of ignorance om my part.
You have two options:
a) if you want to make sure an upgrade doesn't muck with your changed
unit file, just copy the file from /lib/systemd/system/foobar.service to
/etc/sytemd/system/foobar.service and edit it there.
b) If you have a unit file /lib/systemd/system/foobar.service where you
would like to make some minimal changes but have the rest of the
settings updated via at RPM upgrades, then create a new unit file in
/etc/systemd/system/foobar.service, place ".include
/lib/systemd/system/foobar.service" as first line in it and then all
settings you want to override.
Note that a small number of settings are additive though, and won't
override previous settings. For example ReadOnlyDirectories= will always
add an additional read-only dir, not override it was was set before. But
those are very few, and in most cases it should be intuitive which ones
those are (i.e. all those where it makes sense to appear multiple times).
Lennart
--
Lennart Poettering - Red Hat, Inc.
8:43 a.m.
On Wed, 20.07.11 11:06, Nicolas Mailhot (nicolas.mailhot(a)laposte.net) wrote:
I know Fedora has not really pushed multi-instanciation before (but
there are
exceptions, see clamav). But our users do need multi-instanciation and
routinely tweak our init scripts for this reason. They won't appreciate
systemd pulling the carpet under their feet. If systemd is to be adopted, it
needs to make it easier to multi-instanciate, not harder.
I am not sure what precisely you need but systemd actually supports
instantiated services. For example, getty@.service is instantiated 6
times for getty(a)tty1.service, getty(a)tty2.service and so on, from a
single service definition file. As are the fsck service or cryptsetup.
Note that writing around in /usr outside of package installation is not
acceptable, since we want to encourage usage of read-only /usr (and even /).
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:50 a.m.
On Wed, Jul 20, 2011 at 5:43 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Wed, 20.07.11 11:06, Nicolas Mailhot (nicolas.mailhot(a)laposte.net)
wrote:
I am not sure what precisely you need but systemd actually supports
instantiated services. For example, getty@.service is instantiated 6
times for getty(a)tty1.service, getty(a)tty2.service and so on, from a
single service definition file. As are the fsck service or cryptsetup.
Note that writing around in /usr outside of package installation is not
acceptable, since we want to encourage usage of read-only /usr (and even /).
Just for completeness for anyone following along and needs to deal
with multi-instance init take a look at the systemd.unit manpage
specifically the paragraph starting with "Optionally, units may be
instantiated from a template file at runtime."
There is a description of the multi-instance syntax and an enumeration
of the available template variables such as %i and %I which the
existing getty multi-instance examples use.
-jef
2:33 p.m.
On 07/19/2011 07:06 PM, Nicolas Mailhot wrote:
Le mardi 19 juillet 2011 à 18:30 +0000, "Jóhann B.
Guðmundsson" a
écrit :
> Hum best is to provide you with example which daemon do you maintain I
> can convert it for you and provide it to you as an example anyway here's
> an example of a systemd unit that I converted sometime ago for a know
> application named tomcat6 and I'll leave readers to be the judge of that
> what is harder to understand the native systemd unit or the legacy sysv
> init script...
>
> First the converted unit file
> Now the legacy sysv init script that everybody seem to love and cheerish
> so much...
I don't think anyone loves this particular sysv script but you realize I
hope that 99% of its complexity is here to make multi-instanciation
trivial (because when every user can run an IDE like eclipse that wants
its own tomcat instance to play with you *do* need multi-instanciation)
and your unit file does not support this use case at all?
My unit file is just stripped version of what's happening in the basis
once I hear from the maintainers what the desired behaviour I can work
with them to complete the progress.
The bug that contains that very unit file along with a patch that makes
tomcat6 work out of the box has not been touch by the maintainers since
the day I filed it which was 2011-07-06
Not that it actually matters there a plenty of already converted and
shipped units out there that can show the difference of native systemd
units and script messes
JBG
2:53 p.m.
On 22:52:27 Tuesday 19 July 2011 Nicolas Mailhot wrote:
Le mardi 19 juillet 2011 à 18:30 +0000, "Jóhann B.
Guðmundsson" a
écrit :
> Hum best is to provide you with example which daemon do you maintain I
> can convert it for you and provide it to you as an example anyway here's
> an example of a systemd unit that I converted sometime ago for a know
> application named tomcat6 and I'll leave readers to be the judge of that
> what is harder to understand the native systemd unit or the legacy sysv
> init script...
>
> First the converted unit file
>
> Now the legacy sysv init script that everybody seem to love and cheerish
> so much...
I don't think anyone loves this particular sysv script but you realize I
hope that 99% of its complexity is here to make multi-instanciation
trivial (because when every user can run an IDE like eclipse that wants
its own tomcat instance to play with you *do* need multi-instanciation)
and your unit file does not support this use case at all?
Off topic but did anyone managed to use our packaged tomcat with Eclipse
(assuming WTP usage), I personally never managed to make it work so if this
was the reason for the complexity it's not smth that ever worked for me.
Alexander Kurtakov
4:37 p.m.
Le mardi 19 juillet 2011 à 22:53 +0300, Alexander Kurtakov a écrit :
Off topic but did anyone managed to use our packaged tomcat with
Eclipse
(assuming WTP usage), I personally never managed to make it work so if this
was the reason for the complexity it's not smth that ever worked for me.
To be honest while I know many users want this feature I never used it
myself. JPackage's/Fedora's cvs/svn may show who coded all those parts
and I'm quite sure it worked at least in his use-cases or it would not
have been commited. It's not as if one can be proud of this stuff.
--
Nicolas Mailhot
1:41 p.m.
On Tue, 19.07.11 13:59, Fulko Hew (fulko.hew(a)gmail.com) wrote:
> how is shell more transparent? from my meager understanding of
> systemd we are actually getting better more systematic failure and
> logging information from systemd unit files than we get from the
> complexity of shell scripts. Are we not?
>
Up until now, my package is architecture independent.
>From what I understand, I will now have to provide some systemd
application that is coded in C?
If that is the case, I now have to create an RPM per-architecture
and loose my architecture independence.
True or false?
False. systemd spawns shells script just fine, or Python scripts, or
Java, or Mono. From a systemd perspective we just spawn executables and
it is not relevant to systemd which language they are written in and we
support all of them equally well.
(Even if you want to take advantage of some of the fancier systemd
features like socket activation you can do so with no involvement of C
and in any language that runs on Linux. The interface to pass the
sockets from systemd to the services is relly simple and trivial to
recode in other languages. All you need to do is parse $LISTEN_FDS and
$LISTEN_PID and make use of it.)
Lennart
--
Lennart Poettering - Red Hat, Inc.
1 p.m.
On Tue, Jul 19, 2011 at 7:48 PM, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
I disagree this thread specifically boils down to familiarity
argument. Shall I break down the original post point by point?
<snip>
- transparency of code due to shell use
how is shell more transparent?
UNIX sysadmins know shell; so anyone can see what a
shell script does,
and how it can be configured, even if it is not documented. Now tell
me what /lib/systemd/systemd-quotacheck is supposed to do and how it
is configured.
- ease of system setup
straight up familiarity argument. shell based is only easier because
we are familiar with shell and its semantics.
Hm. (systemctl --all |wc -l) is 288
on my system. That's a rather
large number of moving parts, with no obvious way to order them or
understand their relations. I find it very difficult to get an
overall picture of the system, and (systemctl dot) doesn't make it any
better. Perhaps there's a simple trick that I'm missing?
- ease of prototyping, editing, experimenting, etc
straight up familarity argument. How is systemd harder to prototype
with other than the fact we collectively aren't familiar with it yet?
I can
edit a shell script locally (to debug it or add a feature)
without recompiling and without understanding the internal design of
systemd.
Mirek
1:43 p.m.
On 07/19/2011 02:00 PM, Miloslav Trmač wrote:
UNIX sysadmins know shell; so anyone can see what a shell script
does,
and how it can be configured, even if it is not documented. Now tell
me what /lib/systemd/systemd-quotacheck is supposed to do and how it
is configured.
I worked with shell scripts all my life but I hate them, because they
are fragile ahd convoluted. If something goes bad, of course they won't
give you a global traceback, and you can't trace them by hand globally
either---you have to figure out which script calls which script (network
calls ifconfig calls ifup calls ...) and trace them one by one calling
via sh -x.
Hm. (systemctl --all |wc -l) is 288 on my system. That's a
rather
large number of moving parts, with no obvious way to order them or
understand their relations. I find it very difficult to get an
overall picture of the system, and (systemctl dot) doesn't make it any
better. Perhaps there's a simple trick that I'm missing?
If there is I would like to hear it too. However, please consider that
the overall complexity didn't change---you have 288 'services' on your
system with SysV and systemd---it's just that systemd makes the
relationships and dependencies explicit, whereas shell scripts covered
up the complexity partly by serializing and partly by being lucky/having
sorted out by trial and error the order and timing of starting those
services.
It reminds me of symbolic math, which I learned to do on paper but had
to relearn all over how to do using symbolic packages like Mathematica
and Maxima, because they require precise definition of every last detail
which was glossed over in traditional mathematical notation--I am
talking about things like 'can we assume that this variable is always
greater than zero because if not the result is drastically different".
1:09 p.m.
Le mardi 19 juillet 2011 à 09:48 -0800, Jeff Spaleta a écrit :
how is shell more transparent? from my meager understanding of
systemd we are actually getting better more systematic failure and
logging information from systemd unit files than we get from the
complexity of shell scripts. Are we not?
Right now, not at all. Systemd scrapped all kinds of "legacy" logging
and will state on unit failure 'I failed, why I failed must be in some
logs somewhere, go hunt for them'
Not to mention that a sysV script failure can be debuged by feeding the
script to bash -x -v, good luck doing the same in systemd
systemd has a huge potential, but so far a lot of it is just that,
potential, and potential won't make people wait long when they have
clear and present problems caused by the missing bits. I don't think
it's wise to remove more "legacy" stuff before replacing all that's
already been removed. That may be the best path technically but from a
communication POW it's a disaster.
--
Nicolas Mailhot
8:02 a.m.
Nicolas Mailhot wrote:
Le mardi 19 juillet 2011 à 09:48 -0800, Jeff Spaleta a écrit :
> how is shell more transparent? from my meager understanding of
> systemd we are actually getting better more systematic failure and
> logging information from systemd unit files than we get from the
> complexity of shell scripts. Are we not?
Right now, not at all. Systemd scrapped all kinds of "legacy" logging
and will state on unit failure 'I failed, why I failed must be in some
logs somewhere, go hunt for them'
Not to mention that a sysV script failure can be debuged by feeding the
script to bash -x -v, good luck doing the same in systemd
systemd has a huge potential, but so far a lot of it is just that,
potential, and potential won't make people wait long when they have
clear and present problems caused by the missing bits. I don't think
it's wise to remove more "legacy" stuff before replacing all that's
already been removed. That may be the best path technically but from a
communication POW it's a disaster.
I have to agree here. With sysV scripts if some odd things isn't working
you can brute force tracinging it with:
strace -f /etc/init.d/somescript
and chances are you'll find out what went wrong.
AFAIK there is no equivalent in systemd and the status output has not
been useful in the cases I've run into it (again just reporting that the
service didn't start but not why).
rob
12:52 p.m.
On Tue, Jul 19, 2011 at 6:51 PM, seth vidal <skvidal(a)fedoraproject.org> wrote:
On Tue, 2011-07-19 at 08:45 -0800, Jeff Spaleta wrote:
[...]
I agree with one section of your argument:
arguments which are just "I'm not used to this" are bad arguments.
Many of the arguments presented in this and other threads do not boil
down to that.
Well most of them in fact are exactly that.
12:54 p.m.
Jeff Spaleta <jspaleta <at> gmail.com> writes:
...
None of us who are deeply familiar with shell can You easily assess
the relative merits of systemd because we aren't familiar with systemd
yet.
Yes we are already - the discusions here were not useless, neither for me,
you, or anybody else who wanted to understand.
...
I'm utterly unmoved by any arguments which boil down to "I'm familiar
with this 20+ year old tech, and I don't want to learn something new"
...
Not true. We want to bring it to a higher level that would represent true
"progress" and "innovation". A killer init system by any standard
yet.
And the project guys can do it.
Familiar is not automatically easier or better, harder or worse. It
is
simply familiar and the longer we hold on to the familiar the harder
it will every be for us to take the time to invest in better
technologies so we can realize the full potential of those
technologies.
That's what I have just said above too.
So you are already "FOR", but you did not know about it up to now :-)
Welcome to the club !
-jef
JB
4684
days inactive
4686
days old
53 comments
21 participants
participants (21)
-
Adam Jackson -
Adam Williamson -
Aleksandar Kurtakov -
Bill Nottingham -
Dmitry Butskoy -
drago01 -
Frank Murphy -
Fulko Hew -
JB -
Jef Spaleta -
Jóhann B. Guðmundsson -
Kostas Georgiou -
Lennart Poettering -
Michal Schmidt -
Miloslav Trmač -
Nicolas Mailhot -
Przemek Klosowski -
Rob Crittenden -
Seth Vidal -
Steve Dickson -
Stijn Hoop