Bug 713562 - (SysVtoSystemd) Tracker bug for SYSV to systemd conversion
Tracker bug for SYSV to systemd conversion
Status: NEW
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Radek Vokal
Radek Vokal
RejectedBlocker
: Reopened, Tracking
Depends On: 737201 737210 834918 1179453 617321 617326 617330 617331 617333 656886 656891 656911 657216 657412 657494 658116 659605 659633 660089 661220 661223 661230 661241 661255 661325 661387 661389 661632 661648 662461 662714 684175 690766 690828 692154 692157 693891 694454 694738 694932 694940 695584 695589 695597 695736 695741 696114 696147 696427 697523 697532 697533 697600 697612 697636 697645 697653 697664 697698 698204 699038 699040 699289 699292 699293 699441 699785 701230 713572 713573 713574 714426 714430 714439 714642 714647 714649 714668 714683 714685 714688 714698 714702 714705 714710 714715 714874 716441 716904 716923 716970 716984 716994 716997 717227 717397 717419 717479 717564 718025 718168 718171 718172 718175 718177 718183 718186 718197 718602 718603 718654 718701 718756 718785 718793 718818 719283 719371 719406 719419 719434 719437 719462 719610 719637 719655 719657 719886 719890 720065 720071 720078 720079 720175 720184 720193 720210 720275 720443 720445 720448 720513 720515 720521 720523 720526 720976 721088 721354 722324 722341 722348 722352 722356 722450 722629 722631 722632 722635 727193 729344 730154 731427 736988 737147 737168 737183 737212 737219 737244 737258 737281 737667 737676 737682 737695 737705 737708 737710 737725 747639 751856 758201 789901 843042 884641 995753 1179451 1179482 1245876
Blocks: F16Alphas390x F16Alphappc
  Show dependency treegraph
 
Reported: 2011-06-15 15:22 EDT by Stephen Gallagher
Modified: 2015-07-22 23:37 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-26 05:48:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Stephen Gallagher 2011-06-15 15:22:58 EDT
https://fedoraproject.org/wiki/Features/SysVtoSystemd
Comment 1 Stephen Gallagher 2011-06-15 15:24:27 EDT
Services that are installed in the "base" or "core" groups must have their conversion to systemd completed by Fedora 16 Alpha, per FESCo decision on 6/15/2011
Comment 2 Jóhann B. Guðmundsson 2011-06-20 06:40:44 EDT
Note that this has been extended to include all service that get shipped on the Fedora-livecd
Comment 3 Adam Williamson 2011-07-15 13:12:35 EDT
Discussed at the 2011-07-15 blocker review meeting. We agreed that these bugs do not constitute release blockers under the release blocker process - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - which is intended to ensure Fedora releases meet set quality standards, as embodied in the release criteria - https://fedoraproject.org/wiki/Fedora_Release_Criteria .

We are not contesting FESCo's requirement that some of these conversions be complete by Alpha, this is still in effect, but we ask FESCo to manage that through the feature process. A tracker bug outside of the blocker bug process could easily be used to achieve this.
Comment 4 Marcos Mello 2011-09-07 18:32:57 EDT
Missing bug #660069 (Samba)
Comment 5 Jim 2011-12-29 09:57:57 EST
Question: I've just done preupgrade from F15 to F16 and system-config-vsftpd does not work with respect to starting/stopping the server. Is this a new bug or should it be considered part of this or is there some other bug opened on this (I can't find one)?

More details: 
I don't know if it was broken in F15 because, although I had installed vsftp in F15, I had not tried starting/stopping it via system-config-vsftpd. I don't really remember but I think I started it through system-config-services.

When I try to start the server via system-config-vsftpd, it fails with the following message in the Status Log: "sh: /etc/init.d/vsftpd: No such file or directory"

The server will start via command line: /bin/systemctl start vsftpd.service

When started via the above command line, the fact that it is started is not recognized by system-config-vsftpd and thus cannot be stopped by system-config-vsftpd. Xfer Log and System Log do contain information related to vsftp activity performed using the server started by the command line.

Thanks
Jim
Comment 6 Jim 2011-12-29 10:54:45 EST
Did rpm -qa | grep vsftpd and it showed:
system-config-vsftpd-0.5.1-7.fc15.noarch
vsftpd-2.3.4-6.fc16.x86_64

So I've got a back-level version of system-config-vsftpd.

Thanks
Jim
Comment 7 Jim 2011-12-29 11:10:30 EST
OK, never mind. I thought I had done package-cleanup --orphans and gotten rid of obsolete packages but I had not. system-config-vsftpd is obsolete.

Sorry for the diversion.

Jim
Comment 8 Jaroslav Reznik 2013-03-22 08:05:07 EDT
Add Tracking keyword to avoid bug closure during Rawhide rebase process.
Comment 11 Jóhann B. Guðmundsson 2014-05-26 05:48:51 EDT
Given that I have left the project and a new individual may or may not continue with systemd integration in the project by submitting new feature following whatever demands FPC and FESCo might have and thus new units in the process I'm closing this and all remaining bugs I had submitted for this particular feature as WONTFIX
Comment 12 Zbigniew Jędrzejewski-Szmek 2015-01-06 14:04:45 EST
Restore relevant bugs, and reopen.
Comment 13 Jóhann B. Guðmundsson 2015-01-06 16:48:23 EST
Zbigniew any particular reason you reopened this ancient bug ( there was a new bug per release cycle ) as opoosed to simply open a new one and attach all those ca 150 remaining components to be migrated on that one since you seem to be so inclined of working on this as opposed to just leave it up to the project leader left foot and rest of FPC, FESCo and those Red Hat employees that are so inclined of getting in the way of contributors doing needed work for the distribution? 

My advice to you is to leave this mess to be cleaned up by certain Red Hatters on Red Hat's dime since this is what they wanted and this is what they should get and this should be something *they* should do ( along with cron to timers the cleanup of units that should have happened arguable before RHEL 7 got released with systemd etc ).

Focus on preparing the distribution for up coming changes in systemd ( kdbus,networkd etc ) since from the looks of it you and Harald already have your handful dealing first hand with "usefulness" of the FPC trying to prep dracut and systemd for networkd where those fpc geniuses cant even follow they own approved guidelines or realize that there exist no such thing as system wide change anymore due to the distribution moving to products.
Comment 14 Zbigniew Jędrzejewski-Szmek 2015-01-06 17:04:37 EST
(In reply to Jóhann B. Guðmundsson from comment #13)
> Zbigniew any particular reason you reopened this ancient bug
The title and description fits, and it seems less work and noise to simply reopen this one. I don't very high expectations for this to be finished quickly, but having an open tracker bug at least makes it easier to track progress.
Comment 15 Jóhann B. Guðmundsson 2015-01-06 18:17:28 EST
(In reply to Zbigniew Jędrzejewski-Szmek from comment #14)
> (In reply to Jóhann B. Guðmundsson from comment #13)
> > Zbigniew any particular reason you reopened this ancient bug
> The title and description fits, and it seems less work and noise to simply
> reopen this one. I don't very high expectations for this to be finished
> quickly, but having an open tracker bug at least makes it easier to track
> progress.

It's going to cost you up to 300 hours of your life familiarizing yourself with those services/daemon which is required for you to do, so you can a test it when you migrate their legacy sysv initscripts to native systemd units as well as the conversion itself along with those spec file changes and other cleanups you should do based on what other progress is taking place on the core/baseOS to reduce any amount of work in that area. ( which one would be doing in an functional community which Fedora is not )

Those up to 300 hours you could be spending for nothing since the maintainers of those 150 components ( assuming they exist in the first place ) would by now, if interested done the migration themselves so the likely hood is that they a) they dont exist or b) opposed the migration or simply dont know what they are doing thus wont accept those patches is higher than you think so you would be wasted that time for nothing.

In a larger scheme of things those 300 hours of your contributed time with your skill sett is better spent a) directly upstream systemd or b) properly prep and fix python 3.x integration in Fedora ( that is if Toshio and Red Hat's SCL let by Marcela has not royally thwarted that effort for the distribution ) and finally c) simply with your family.

Let this and other integration/migration work be handled by Red Hat employees since they are incapable of accepting responsibility for the outcome of the decisions they make and the position they are in.

The only way they will learn is having them to do all the hard work themselves since they are incapable of listening as in by bumping into those things them themselves.

Note You need to log in before you can comment on or make changes to this bug.