Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

["Jóhann B. Guðmundsson"]

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