On 11/09/2011 05:49 AM, Ian Kent wrote:
>> What other form of encouragement can you suggest?
> This email thread for a start.
We have had email threads like this for two release cycles now and yet
the main problem still remains the same packagers/maintainers not either
migrating themselves or they not packaging submitted unit files...
>
> I'm not hurrying to make changes to my package because I've had problems
> a couple of times now because of what I consider poor documentation or a
> lack of information about where to find documentation. This isn't
> specific to systemd at all.
The man pages for systemd are really and I mean really good as has been
pointed out several times along with upstream documentation and
Lennart's blog posts which usually tackle anykind of gray area the
previous mention documentation do not cover.
That as also has been stated serveral times and once again now for the
third developement cycle that systemd has been the default init system.
> Recent bugs relating to startup problems haven't been worked on because
> of ongoing confusion over other init mechanisms and the lack of
> assistance in terms of adequate documentation, at least as far as what I
> was pointed to.
I'm not sure who and what you have been pointed to but when in doubt ask
upstream and systemd is no exception from that general rule of thumb.
So ask what you have not yet been answered on systemd-devel list or on
the systemd channel on freenode both of which are very active...
> The documentation link in this thread however is somewhat more useful
> but that implies that there is a huge amount of work to do on my daemon
> and that will take time. Assuming I do get a pointer to adequate
> documentation to unit file construction I'll then start on daemon work.
>
> But don't forget, this is not high priority because the daemon itself
> does work OK, except for the startup order dependency difficulties that
> have arisen, which weren't introduced by me.
If you are looking for somekind of spoon feeding migration documentation
it has not been written since for the most part the migration process
needs to be handle on case by case bases and that migration process
works best ( and at the same time fastest ) when
upstream/maintainers/packagers work with those of us that have been
migrating legacy sysv init scripts to native systemd units not against us.
Now taking a quick look at the autofs service which I assume you are
referring too I'm not seeing anykind of massive rewrite in order for the
daemon ( which generally is an exception that a rule ) to work in
systemd unit so from a quick and convertion on top of my head while
writing this, here's a unit file which you can start as your base point
to work on.
### autofs.service ###
[Unit]
Description=Automounts filesystems on demand
Requires=ypbind.service
After=network.target ypbind.service
[Service]
Type=forking
PIDFile=/run/autofs.pid
EnvironmentFile=-/etc/sysconfig/autofs
ExecStart=/usr/sbin/automount ${OPTIONS} --pid-file /run/autofs.pid
[Install]
WantedBy=multi-user.target
The load module and check section has been drop since loading modules in
systemd unit is frowned upon and rightly so since kmods these days can
be autoloaded on use and those that cant should drop an conf file for
that module load into /etc/modules-load.d/ directory.
If yours cant be autoloaded on use here's a conf file that loads that
module.
### autofs.conf ###
# Load autofs module at boot
autofs4
That only leaves this relevant sections from that quick look that needs
some work and remains questionable if that should be handled in unit
file et all...
# Check misc device
if [ -n "$USE_MISC_DEVICE" -a "x$USE_MISC_DEVICE" = "xyes" ]; then
sleep 1
if [ -e "/proc/misc" ]; then
MINOR=`awk "/$DEVICE/ {print \\$1}" /proc/misc`
if [ -n "$MINOR" -a ! -c "/dev/$DEVICE" ]; then
mknod -m 0600 /dev/$DEVICE c 10 $MINOR
fi
fi
if [ -x /sbin/restorecon -a -c /dev/$DEVICE ]; then
/sbin/restorecon /dev/$DEVICE
fi
else
if [ -c /dev/$DEVICE ]; then
rm /dev/$DEVICE
fi
fi
> So, to sum up, this thread has encouraged me to look further into
> systemd support and a heavy handed approach will not make that go any
> faster.
Well people have had 2 whole development cycles to get with the program,
three if you count the first time we tried to push this through as in
F14 and yet people have not done it already ( even if they have been
submitted unit files to use ) which clearly points out to that
packagers/maintainers aren't maintaining their packages or have been
living under a rock and arent involved/paying attention on what's
happening in Fedora.
One would think that 12 months ( 18 if you count in the equation the
initial introduction to fedora ) would be sufficient time for people to
get up to speed but as it turns out it isn't hence using a heavy hand as
you put it will result in a) unit's being made and shipped or b)
unmaintained/poorly maintained packages removed both of which do the
community good.
Ofcourse if you have any other suggestion than using a heavy hand to
speed up the migration and the general adoption of systemd feel free to
share it.
JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
