Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 2 12 LastLast
Results 1 to 10 of 15
  1. #1
    Senior Member
    Join Date
    Feb 2007
    Location
    Vancouver, BC
    Posts
    122

    Fedora service control fumbles after server restart

    I've just upgraded to 7.6.2 and discovered the restart feature after plugins are installed, etc.

    My server is installed on Fedora as a service which is controlled via:
    Code:
    service squeezeboxserver { start | stop }
    I discovered that the service control is unable to stop the server if the server previously been restarted (eg a plugin had previously been installed).

    The root cause is that pidof(8) is unable to find the newly minted server for the following reasons:
    • pidof(8) is looking for a script by comparing comm field in /proc/<pid>/stat with the basename of argv[1].
    • When started as a service, the server relies on the #! in slimserver.pl to run the script. This causes the executable to have a comm value of (slimserver.pl).
    • When the server restarts itself, it uses the command line equivalent of "perl slimserver.pl ..." and the newly minted instances gets a comm field value of (perl).
    • pidof(8) can no longer find the script process running the server.


    The problem is potentially resolved by using:

    Code:
        exec($0, $0, @argv);
    in sub stopServer, but that won't work on all platforms.

    Perhaps a better approach is to change Slim/Utils/OS.pm to provide a platform specific restart method:

    Code:
    sub performRestart {
            exec($0, $0, @_)
    }
    Is this a reasonable approach ?

  2. #2
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,630

    Fedora service control fumbles after server restart

    > The problem is potentially resolved by using:
    >
    > Code:
    > --------------------
    > exec($0, $0, @argv);
    > --------------------


    Does this work for you? You might want to file a bug report (if there
    isn't one already?) attaching a patch.

    > Perhaps a better approach is to change Slim/Utils/OS.pm to provide a
    > platform specific restart method:


    Descendents of Slim::Utils::OS (in the OS sub-folder) can implement a
    restartServer method. Windows OSX are using this.

    --

    Michael

  3. #3
    Senior Member gharris999's Avatar
    Join Date
    Apr 2005
    Location
    Santa Fe, NM
    Posts
    3,529
    Quote Originally Posted by mherger View Post
    You might want to file a bug report (if there
    isn't one already?)
    Bug filed nearly two years ago on this: http://bugs.slimdevices.com/show_bug.cgi?id=15523

  4. #4
    Senior Member Mnyb's Avatar
    Join Date
    Feb 2006
    Location
    Vństerňs Sweden
    Posts
    16,528
    Voted ! Seen this forever on my OS
    --------------------------------------------------------------------
    Main hifi: Rasbery PI digi+ MeridianG68J MeridianHD621 MeridianG98DH 2 x MeridianDSP5200 MeridianDSP5200HC 2 xMeridianDSP3100 +Rel Stadium 3 sub.
    Bedroom/Office: Boom
    Loggia: Raspi hifiberry dac + Adams
    Bathroom : Radio (with battery)
    iPad with iPengHD & SqueezePad
    (spares Touch, SB3, reciever ,controller )
    server Intel NUC Esxi VM Linux mint 18 LMS 7.9.2

    http://people.xiph.org/~xiphmont/demo/neil-young.html

  5. #5
    Senior Member
    Join Date
    Feb 2007
    Location
    Vancouver, BC
    Posts
    122
    Quote Originally Posted by mherger View Post
    > The problem is potentially resolved by using:
    >
    > Code:
    > --------------------
    > exec($0, $0, @argv);
    > --------------------


    Does this work for you? You might want to file a bug report (if there
    isn't one already?) attaching a patch.
    Yes, this is sufficient to fix the problem.

    The key is that relying on "#!" to run a script gets the name of the script (slimserver.pl) in /proc/pid/stat, while using "perl slimserver.pl" gets the name of the intepreter (perl) in /proc/pid/stat.

    pidof(8) finds the script in the former case, and fails to find the process in the latter.

  6. #6
    Senior Member
    Join Date
    Feb 2007
    Location
    Vancouver, BC
    Posts
    122
    Quote Originally Posted by gharris999 View Post
    Bug filed nearly two years ago on this: http://bugs.slimdevices.com/show_bug.cgi?id=15523
    Ok. I'll work up a patch against this.

  7. #7
    formerly known as Fletch
    Join Date
    May 2005
    Posts
    2,305
    Much of the ugliness in that script is a result of my poor attempts a couple years ago to make it work on multiple versions of Fedora, CentOS and SuSE. A clean look at it would be very useful.

  8. #8
    Senior Member
    Join Date
    Feb 2007
    Location
    Vancouver, BC
    Posts
    122
    Quote Originally Posted by Mark Miksis View Post
    Much of the ugliness in that script is a result of my poor attempts a couple years ago to make it work on multiple versions of Fedora, CentOS and SuSE. A clean look at it would be very useful.
    For clarity, which script are you referring to ?

    This one ?

    http://svn.slimdevices.com/slim/7.6/...32&view=markup

  9. #9
    formerly known as Fletch
    Join Date
    May 2005
    Posts
    2,305
    Quote Originally Posted by quietdragon View Post
    For clarity, which script are you referring to ?

    This one ?

    http://svn.slimdevices.com/slim/7.6/...32&view=markup
    No, I'm referring to the one in platforms/redhat which is used for the RPM. I don't think the platforms/fedora directory was ever used for any official builds.

  10. #10
    Senior Member
    Join Date
    Feb 2007
    Location
    Vancouver, BC
    Posts
    122
    Quote Originally Posted by Mark Miksis View Post
    No, I'm referring to the one in platforms/redhat which is used for the RPM. I don't think the platforms/fedora directory was ever used for any official builds.
    Oh. You mean this one:

    http://svn.slimdevices.com/slim/7.6/...32&view=markup

    I didn't really notice anything amiss with the Fedora script. Both this and the Redhat one call killproc, which in turn uses pidof(8), which lands us in the scenario which I described.

    I think another way to work around this problem would be for the script (both Redhat and Fedora) to record the pid of slimserver.pl in a pidfile.

    For this to work, the slimserver.pl process must not change pids. This would require the other defect I logged to be fixed:

    http://bugs.slimdevices.com/show_bug.cgi?id=17730

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •