1. Forum
  2. FidoNet
  3. ALT.OS.LINUX.MAGEIA

  • Cups service race condition returned.

    From Doug Laidlaw@2:250/1 to All on Fri Dec 13 13:50:21 2019
    Running Mga 7 I see:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Starting CUPS Scheduler...
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service:
    Succeeded.
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Stopped CUPS
    Scheduler.

    Then:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service:
    Start request repeated to> <yada, yada as before>

    My question is: the service was started successfully. Why was it stopped?

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Fri Dec 13 14:07:46 2019
    On Sat, 14 Dec 2019 00:50:21 +1100, Doug Laidlaw wrote:
    Running Mga 7 I see:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Starting CUPS Scheduler...
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service: Succeeded.
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Stopped CUPS
    Scheduler.

    Did you know about the --no-hostname option. It is handy to for cutting
    down the journal noise and would save wasted space on all Usenet servers
    and last, and not least, make it easier for anyone reading your post.



    Then:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service:
    Start request repeated to> <yada, yada as before>

    My question is: the service was started successfully. Why was it stopped?

    Luke, use the force (journalctl).

    I do not see how in the hell you would expect us to know what was going
    on at the time of the desired event.


    At this point all I can suggest is:
    1. Create a guest account
    2. put it in the systemd-journal group so it can view the journal
    without having to be root.
    3. post guest account id and password
    4. poke a hole in router and system firewalls to allow ssh access
    5. give us your WAN/Internet address.

    That way we can login and look in the journal, and any criminal
    can see if they can gain root control of you system.




    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Doug Laidlaw@2:250/1 to All on Fri Dec 13 14:23:16 2019
    On 14/12/19 1:07 am, Bit Twister wrote:
    On Sat, 14 Dec 2019 00:50:21 +1100, Doug Laidlaw wrote:
    Running Mga 7 I see:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Starting CUPS
    Scheduler...
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service:
    Succeeded.
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Stopped CUPS
    Scheduler.

    Did you know about the --no-hostname option. It is handy to for cutting
    down the journal noise and would save wasted space on all Usenet servers
    and last, and not least, make it easier for anyone reading your post.

    No, I hadn't heard of it. It is a trick worth knowing about.


    Then:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service:
    Start request repeated to> <yada, yada as before>

    My question is: the service was started successfully. Why was it stopped?

    Luke, use the force (journalctl).

    I do not see how in the hell you would expect us to know what was going
    on at the time of the desired event.

    I expected that there was a known system call that automatically shuts
    down what is started up. I cannot see that it would be of any use, but
    there has to be a reason. I don't know if I could change the sequence
    of services to avoid this bottleneck, but I doubt it.

    At this point all I can suggest is:
    1. Create a guest account
    2. put it in the systemd-journal group so it can view the journal
    without having to be root.
    3. post guest account id and password
    4. poke a hole in router and system firewalls to allow ssh access
    5. give us your WAN/Internet address.

    That way we can login and look in the journal, and any criminal
    can see if they can gain root control of you system.



    Very funny! In other words, this is the last place I should look for help.


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (2:250/1@fidonet)
  • From Doug Laidlaw@2:250/1 to All on Fri Dec 13 14:32:54 2019
    On 14/12/19 1:23 am, Doug Laidlaw wrote:
    Very funny! In other words, this is the last place I should look for help.

    I can usually find an answer sooner on the Ubuntu or Arch forums, which
    are always busy. Arch deals with the underlying kernel, without making
    it fit into a packaging system, and explains not only the How, but the
    Why as well.

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (2:250/1@fidonet)
  • From TJ@2:250/1 to All on Fri Dec 13 16:06:32 2019
    On 12/13/19 8:50 AM, Doug Laidlaw wrote:
     Running Mga 7 I see:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Starting CUPS Scheduler...
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service: Succeeded.
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Stopped CUPS Scheduler.

    Then:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service:
    Start request repeated to> <yada, yada as before>

    My question is: the service was started successfully.  Why was it stopped?

    I had thought that the race condition had gone away when I upgraded my motherboard/processor, because since then whenever I go to print
    something cups is up and running. However, after your post I decided to
    run, as root, this command:

    journalctl -ab --no-hostname | grep cups

    The result indicates the race condition still exists. I don't know why
    my cups service is working anyway.

    Remember the bug for this? Some users have reported there that if they
    boot with the printer powered down the service starts, but if they boot
    with it powered up it doesn't.

    IMO, this is one of those times when you won't get the answer you seek
    here. You need to consult with a developer, and most of those don't
    follow this newsgroup.

    TJ

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Fri Dec 13 16:37:25 2019
    On Fri, 13 Dec 2019 11:06:32 -0500, TJ wrote:
    On 12/13/19 8:50 AM, Doug Laidlaw wrote:
     Running Mga 7 I see:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Starting CUPS
    Scheduler...
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service:
    Succeeded.
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Stopped CUPS
    Scheduler.

    Then:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service:
    Start request repeated to> <yada, yada as before>

    My question is: the service was started successfully.  Why was it stopped?

    I had thought that the race condition had gone away when I upgraded my motherboard/processor, because since then whenever I go to print
    something cups is up and running. However, after your post I decided to
    run, as root, this command:

    journalctl -ab --no-hostname | grep cups

    The result indicates the race condition still exists. I don't know why
    my cups service is working anyway.

    Remember the bug for this? Some users have reported there that if they
    boot with the printer powered down the service starts, but if they boot
    with it powered up it doesn't.

    IMO, this is one of those times when you won't get the answer you seek
    here.

    Providing absolutely no information other than the problem will not get
    you much farther in an help forum.

    You need to consult with a developer, and most of those don't
    follow this newsgroup.

    Developer is still going to want the user to recreate the problem reliably. Provide the chain of events that cause the problem.
    Hopefully user has used journal --since="date/time minus a few minutes"
    before the restart to see if there is something of interest and looked
    around in the cups log directory.

    Example: I just now powered up my Brother laser/scanner printer.

    kernel: usb 2-1: new high-speed USB device number 4 using ehci-pci
    kernel: usb 2-1: New USB device found, idVendor=04f9, idProduct>
    kernel: usb 2-1: New USB device strings: Mfr=0, Product=0, Seri>
    kernel: usb 2-1: SerialNumber: U63886G4N232108
    kernel: usblp 2-1:1.0: usblp0: USB Bidirectional printer dev 4 >
    systemd[1]: Listening on CUPS Scheduler.
    systemd[1]: Started Configure Plugged-In Printer.
    mtp-probe[11076]: checking bus 2, device 4: "/sys/devices/pci00>
    mtp-probe[11076]: bus: 2, device: 4 was not an MTP device
    udev-configure-printer[11077]: package task-printing-server is not installed
    udev-configure-printer[11077]: Cups isn't installed, let's install it
    udev-configure-printer[11077]: InstallSpooler()
    udev-configure-printer[11077]: CheckInstalledSpooler()
    udev-configure-printer[11077]: InstallSpoolerFailed()
    systemd[1]: configure-printer@usb-002-004.service: Main process exited, code=exited, status=1/FAILURE
    systemd[1]: configure-printer@usb-002-004.service: Failed with result 'exit-code'.

    and yet I have no problem printing via cups.


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Fri Dec 13 19:56:22 2019
    On 2019-12-13, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:
    Running Mga 7 I see:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Starting CUPS Scheduler...
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service: Succeeded.
    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: Stopped CUPS Scheduler.

    Then:

    Dec 13 23:29:22 dougshost.douglaidlaw.net systemd[1]: cups.service:
    Start request repeated to> <yada, yada as before>

    My question is: the service was started successfully. Why was it stopped?

    There is abug in Mga7 cups which causes it to behave like that. It seems
    to be rare (ie some peculiarity of your hardware/software) but is really annoying to those who suffer from it. If you restart cups once your
    system has booted it will probably startup fine.

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Fri Dec 13 20:05:39 2019
    On 2019-12-13, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:
    On 14/12/19 1:07 am, Bit Twister wrote:

    At this point all I can suggest is:
    1. Create a guest account
    2. put it in the systemd-journal group so it can view the journal
    without having to be root.
    3. post guest account id and password
    4. poke a hole in router and system firewalls to allow ssh access
    5. give us your WAN/Internet address.

    That way we can login and look in the journal, and any criminal
    can see if they can gain root control of you system.



    Very funny! In other words, this is the last place I should look for help.


    No. Bittwister just got out of bed grumpy today. He is usually very
    helpful, but we all have those days when everyone in the world pisses us
    off.

    As I stated this seems to be a bug that noone knows what causes it. It
    seems to be rare, so it is hard to duplicate for those who might be able
    to fix it (Apple?)

    Try putting a
    systemctl restart cups
    into /etc/rc.d/rc.local

    it might help.

    Or try putting

    @reboot systemctl restart cups

    into root crontab.

    No guarentee these will work -- I do not have the problem and do not
    need these.



    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Fri Dec 13 23:03:44 2019
    On Fri, 13 Dec 2019 20:05:39 -0000 (UTC), William Unruh wrote:
    On 2019-12-13, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:
    On 14/12/19 1:07 am, Bit Twister wrote:

    At this point all I can suggest is:
    1. Create a guest account
    2. put it in the systemd-journal group so it can view the journal
    without having to be root.
    3. post guest account id and password
    4. poke a hole in router and system firewalls to allow ssh access
    5. give us your WAN/Internet address.

    That way we can login and look in the journal, and any criminal
    can see if they can gain root control of you system.



    Very funny! In other words, this is the last place I should look for help. >>

    No. Bittwister just got out of bed grumpy today. He is usually very
    helpful, but we all have those days when everyone in the world pisses us
    off.

    I'll have you know I am the most even tempered man in town, mad all the time. :)

    Just trying to get Doug's attention, again, and lurkers, to always provide information instead just a post with no other usable information.


    As I stated this seems to be a bug that noone knows what causes it. It
    seems to be rare, so it is hard to duplicate for those who might be able
    to fix it (Apple?)

    Try putting a
    systemctl restart cups
    into /etc/rc.d/rc.local

    it might help.

    Or try putting

    @reboot systemctl restart cups

    into root crontab.

    No guarentee these will work -- I do not have the problem and do not
    need these.

    Yep, I will go along with that guarantee.

    At first glance of the post, Doug has already indicated he gets a cups
    restart after cups was up.

    On my system, my new_boot_logs script disables cups. I do that just
    to have one less service running for a criminal to have in an attempt
    to get root privs.

    What I have noticed is that I can power up the printer, and print without having to start cups. Apparently cups is started upon udev finding the
    new usb connect.

    Your suggestions are just a one-shot restart. If a service is failing
    to run or just going down for some reason and you always want it running,
    on a systemd setup, the proper way is to create a drop in file with
    the command to restart on abnormal termination.

    For drop in file creation, you create a
    /etc/systemd/system/whatever.service.d directory, and a file with
    whatever commands/values desired to add to the service setup.

    For example, I want mythbackend to automagically restart if it crashes
    and I do not want it started until dhcpd has started. I have dhcpd
    assigning ip addresses to my network tv tuners.

    To do so I do a
    mkdir --parents /etc/systemd/system/mythbackend.service.d

    In the event that there maybe more than one file, I want my drop in file
    to run last so I created
    /etc/systemd/system/mythbackend.service.d/xx__mythbackend.conf
    There is where I set desired parameters and directives.

    # cat /etc/systemd/system/mythbackend.service.d/xx__mythbackend.conf #****************************************************
    #
    # Created by /local/bin/mythtv_changes Mon 12 Aug 05:24 2019
    #
    #****************************************************

    [Unit]
    After=dhcpd.service
    StartLimitBurst=3
    StartLimitIntervalSec=30
    StartLimitAction=none

    [Service]
    Restart=on-abnormal

    #***end /etc/systemd/system/mythbackend.service.d/xx__mythbackend.conf **

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Sat Dec 14 05:42:17 2019
    On 2019-12-13, Bit Twister <BitTwister@mouse-potato.com> wrote:
    On Fri, 13 Dec 2019 20:05:39 -0000 (UTC), William Unruh wrote:
    On 2019-12-13, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:
    On 14/12/19 1:07 am, Bit Twister wrote:

    At this point all I can suggest is:
    1. Create a guest account
    2. put it in the systemd-journal group so it can view the journal
    without having to be root.
    3. post guest account id and password
    4. poke a hole in router and system firewalls to allow ssh access
    5. give us your WAN/Internet address.

    That way we can login and look in the journal, and any criminal
    can see if they can gain root control of you system.



    Very funny! In other words, this is the last place I should look for help. >>>

    No. Bittwister just got out of bed grumpy today. He is usually very
    helpful, but we all have those days when everyone in the world pisses us
    off.

    I'll have you know I am the most even tempered man in town, mad all the
    time. :)

    Just trying to get Doug's attention, again, and lurkers, to always provide information instead just a post with no other usable information.

    Actually there was some useable information in there. That his cups was
    coming up and immediately going down time after time. That reminded me
    of other posts with those symptoms and the fact that there was no other
    info in the logs to help figure out why cups was doing that. Ie, there
    is no other information he could have given. I could be wrong, but your
    jumping down his throat was uncalled for in this case.



    As I stated this seems to be a bug that noone knows what causes it. It
    seems to be rare, so it is hard to duplicate for those who might be able
    to fix it (Apple?)

    Try putting a
    systemctl restart cups
    into /etc/rc.d/rc.local

    it might help.

    Or try putting

    @reboot systemctl restart cups

    into root crontab.

    No guarentee these will work -- I do not have the problem and do not
    need these.

    Yep, I will go along with that guarantee.

    At first glance of the post, Doug has already indicated he gets a cups restart after cups was up.

    Yes, and then another and another and another. There is something that
    is causing this yoyoing on boot some machines. It would be great to
    figure out what is causing this.


    On my system, my new_boot_logs script disables cups. I do that just
    to have one less service running for a criminal to have in an attempt
    to get root privs.

    From other reports, if cups is started after boot is over, it comes up
    without trouble. YOu are not starting it during boot.

    And it may be that on Mga7 cups is automatically started when a printer
    is plugged in. (I assume that that printer had to have been installed
    into cups beforehand).


    What I have noticed is that I can power up the printer, and print without having to start cups. Apparently cups is started upon udev finding the
    new usb connect.

    Your suggestions are just a one-shot restart. If a service is failing
    to run or just going down for some reason and you always want it running,
    on a systemd setup, the proper way is to create a drop in file with
    the command to restart on abnormal termination.

    From past reports, starting cups again after boot is over is what is
    needed. At that point the system becomes the same as it would be had
    cups started at boot. YOur system assumes that the only thing cups needs
    to do is to print from that machine, not run any daemon listening for
    other machines to request printing, not broadcast its service to other machines, etc. If that is your use-case then just not starting cups and
    hoping that something will automatically start it may well be the best
    option.



    For drop in file creation, you create a
    /etc/systemd/system/whatever.service.d directory, and a file with
    whatever commands/values desired to add to the service setup.


    There already is a service starting cups and restarting it if cups goes
    down. Something is misbehaving. Having yet another service doing the
    same thing does not sound terribly useful. And if you want to start cups
    after bootup, service restart cups should be all you need.



    For example, I want mythbackend to automagically restart if it crashes
    and I do not want it started until dhcpd has started. I have dhcpd
    assigning ip addresses to my network tv tuners.

    To do so I do a
    mkdir --parents /etc/systemd/system/mythbackend.service.d

    In the event that there maybe more than one file, I want my drop in file
    to run last so I created
    /etc/systemd/system/mythbackend.service.d/xx__mythbackend.conf
    There is where I set desired parameters and directives.

    # cat /etc/systemd/system/mythbackend.service.d/xx__mythbackend.conf #****************************************************
    #
    # Created by /local/bin/mythtv_changes Mon 12 Aug 05:24 2019
    #
    #****************************************************

    [Unit]
    After=dhcpd.service
    StartLimitBurst=3
    StartLimitIntervalSec=30
    StartLimitAction=none

    [Service]
    Restart=on-abnormal

    #***end /etc/systemd/system/mythbackend.service.d/xx__mythbackend.conf **

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Sat Dec 14 22:13:44 2019
    On 14/12/19 10:03 am, Bit Twister wrote:


    I'll have you know I am the most even tempered man in town, mad all the
    time. :)



    Can I use that!? :-) :-)



    --
    faeychild
    Running plasmashell 5.15.4 on 5.3.13-desktop-2.mga7 kernel.
    Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)