Syndaemon does not have a switch to run as a daemon. When it is started from the init script, it will display output to stdout and keep control of the terminal. (essentially, it won't daemonize itself) Reproducible: Always Steps to Reproduce: 1. Emerge synaptics 2. /etc/init.d/syndaemon 3. Command prompt is not returned until program is killed via ctrl-c. Expected Results: It should have daemonized and run in the background, returning the command prompt to me. All that needs to be done is to change line 12 of /etc/init.d/syndaemon from: syndaemon ${SYNDAEMON_OPTS} to: syndaemon ${SYNDAEMON_OPTS} >/dev/null & That will cause it to stop outputting to the terminal and return the command prompt. Unfortunately, it also means it can't be stopped via the init script. I think this needs to be handled by the start-stop-daemon. I don't know how to do that.
Good to hear from you. I've been waiting for some feedback on that, as I can't get syndaemon to run at all over here. I'll post a new script/patch shortly for you to test.
In my case the whole init script is useless since it tries to start the syndaemon before the X-Server has finished starting. The result is an error message from syndaemon "Could not open display". Syndaemon needs to be started after the X-Server has finished starting. My solution was to put "syndaemon -i1 &" to /home/.../.kde/Autostart/start.sh
I'd greatly appreciate it if someone would take the time to modify/fix the init script. I've been distracted by other things lately.
Created attachment 32110 [details] /etc/conf.d/syndaemon
Created attachment 32114 [details] /etc/init.d/syndaemon Well, there is it. It have a lot of problems but it must work is some situations. 1. It can not be added in any runlevel hoping that it will start during boot. ============================================================================= This is because they have /etc/init.d/xdm has a dependency and {gdm,kdm,xdm} do not start until the runlevel `3` (default) finish startup. {gdm,kdm,xdm} starts on runlevel `a` (see startDM.sh). I dont know[1] how to workaround that without modifying anything that does not belong to the synaptics ebuild. ============================================================================= 2. It does not work if you start your X Session with startx and run the /etc/init.d/syndaemon in a console. (it works if you run it inside a virtual console inside your X Session) ============================================================================= It can be fixed but this is a service/daemon and its illogical to start up manually without having a dependency. The workaround is: remove the need xdm in the function depend() and in another function check that if a DM is the one that is running or a startx command. If a startx is detected look for who user started and merge her xauthority (magic cookie) to root. In this way the possibilities that it works when starting up (has a init script) the computer are smaller. (cos we loose the dependency) ============================================================================= 3. Not work if you are using entrance as your DM ============================================================================= I dont have (and i dont want to install) entrance. If you are using entrance put the output of a `ps -o command -C 'X'` ============================================================================= 4. Not work if you session are in :1, :2, :3.... ============================================================================= And maybe never work, lot of complexity for a init script i think. Each DM put their magic cookie where it like. ============================================================================= This is a very very very ugly init script but maybe work for you. The important changes are: /etc/conf.d/syndaemon: You only need to put the seconds there is no more arguments and updated headers. /etc/init.d/syndaemon: Updated headers, use start-stop-daemon, and get (in the better way that i know) the magic cookie in order to run it outside the X Session. Maybe the real solution is not an init script, I think is better to remove it or make an script and put it in some place in order to run it in local script[1] (waiting for a X session) or just adding syndaemon in $HOME/Desktop/Autostart. I hope it helps in some manner.
/etc/X11/xinit/xinitrc.d/ or /etc/X11/Xsession.d/ are better choices for the script location. Especially the first I guess (which is also used by numlockx). Can you fix it, now that it has been reported?
*** Bug 80979 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > All that needs to be done is to change line 12 of /etc/init.d/syndaemon from: > > syndaemon ${SYNDAEMON_OPTS} > > to: > > syndaemon ${SYNDAEMON_OPTS} >/dev/null & > > That will cause it to stop outputting to the terminal and return the command > prompt. Hi, I guess it's not the correct thing to do. I changed /etc/conf.d/syndaemon on line 8. The COMMENTED variable SYNDAEMON_OPTS MUST be set by default during instalation to: SYNDAEMON_OPTS="-d -p /var/run/syndaemon.pid". This create the .pid file that makes is possible do stop syndaemon and makes it starts as a deamon. Nothing else should be changed, I guess. Only this change works for me. []'s Glauber
Created attachment 65089 [details] /etc/init.d/syndaemon I believe too that /etc/init.d is the wrong directory for syndaemon since it requires X. But apart from this it doesn't work as it is now. I attach an alternative default /etc/init.d/syndaemon that at least makes it working (see comment #8) if you do "/etc/init.d/syndaemon start|stop".
Created attachment 65090 [details, diff] patch against synaptics-0.14.3.ebuild I also attach a patch against synaptics-0.14.3.ebuild that IMHO makes files in init.d and conf.d in a more elegant way.
IMO, The -d and -p options should be placed in the init script, following best practices of other init scripts. IOW, syndaemon should "just work" even if the user doesn't config the file in /etc/conf.d. The attached /etc/init.d/syndaemon files do that using start-stop-daemon but I don't think that is necessary to use start-stop-daemon. There is default behavior that makes this unnecessary. IOW, if you just make the existing line read: "/usr/X11R6/bin/syndaemon -d -p /var/run/syndaemon.pid ${SYNDAEMON_OPTS}" then it gets started and stopped correctly. WRT whether or not this should be an init item: I suggest this behavior should just be built into the driver with a xorg-conf item setting the delay. That would obviate the entire problem wouldn't it?
Thinking just a little more about this, I discovered that syndaemon (the program) works mostly OK when run from my GDM session, and maybe that is the correct way of using this program: as a session-specific item. It DOES seem like it shouldn't be system-wide, in case different users have different preferences. (Yes, I know, laptops typically don't have different users, but there is no fundamental reason why this shouldn'be done right...) The problem is that syndaemon hangs the startup for a long time used this way, whether or not the -d option is specified. After a minute or two the session startup continues and syndaemon works fine. Maybe there is a way to fix that?
Well, this thing simply doesn't work at all, neither as init script (pretty much expected), not from xinitrc.d, nor manually from within X session. The only this I get is "Can't open display" no matter what. Good luck with this.
(In reply to comment #13) > Well, this thing simply doesn't work at all, neither as init script (pretty > much expected), not from xinitrc.d, nor manually from within X session. The > only this I get is "Can't open display" no matter what. Good luck with this. That's probably because of missing Xauth as it works for me when I invoke the daemon directly from a terminal. I'm not familiar with X architecture, but I guess it won't work after a restart of X session despite any magic we do with Xauth hacking, so I'd just remove the init script and add a note into the ebuild asking users to put it into their X startup config...
(In reply to comment #14) > and add a note into the ebuild asking users to put it into their X startup > config... That doesn't work (or I don't get what you mean by 'X startup config'). As said above, the syndaemon thing plain won't work no matter what and where you do.
(In reply to comment #12) > The problem is that syndaemon hangs the startup for a long time used this way, > whether or not the -d option is specified. After a minute or two the session > startup continues and syndaemon works fine. Maybe there is a way to fix that? This problem no longer occurs. At least for synaptics-0.14.6. I just put "syndaemon" in my GDM startup programs and it works. I'd recommend all the other ways of starting syndaemon be deprecated and this method be documented as the recommended one.
bla # syndaemon -i 1 -d bla # ps aux|grep synd root 5799 0.2 0.0 2768 352 ? Ss 17:14 0:00 syndaemon -i 1 -d bla # killall syndaemon bla #cat /etc/conf.d/syndaemon |grep -i opts SYNDAEMON_OPTS="-i 1 -d" bla # /etc/init.d/syndaemon start * Starting syndaemon ... Can't open display. [!!] > start() { > ebegin "Starting syndaemon" > /usr/bin/syndaemon ${SYNDAEMON_OPTS} > eend $? >} WTF ?
Well, can we finally send the initscript the way of the dodo? Regardless of what's the correct/working place, initscript is definitely not one, it's just completely useless and confusing users.
(In reply to comment #18) > Well, can we finally send the initscript the way of the dodo? Regardless of > what's the correct/working place, initscript is definitely not one, it's just > completely useless and confusing users. I'm agree, at least is a *real* solution for this bug which as been opened for 4 years.
Alternatively, we could make the init script work. Continuing on BlaisorBlade's idea in comment #6, make the init script create the needed shell script in /etc/X11/xinit/xinitrc.d/ when started, and delete it when stopped. Updated init script attached ...
Created attachment 191623 [details] /etc/init.d/syndaemon Syndaemon init script
Created attachment 191628 [details] /etc/init.d/syndaemon *Edit* Only have the einfo message display if creation of the script is successful.
Having an init script create and remove another init script is even more confusing IMHO. Also, is there a need to create and remove the script in /etc/X11, instead of doing it statically? If the service startup is automated, that's useless; if the service startup is not automated... well, just make the user modify a config file if he wants, or just stop the daemon.
(In reply to comment #23) > Having an init script create and remove another init script is even more > confusing IMHO. Also, is there a need to create and remove the script in > /etc/X11, instead of doing it statically? If the service startup is automated, > that's useless; if the service startup is not automated... well, just make the > user modify a config file if he wants, or just stop the daemon. > The idea is to have the root user be able to globally enable/disable daemons that require an X11 session, via the init.d services, for all X11 sessions. The same principle in future could equally apply to any daemon or program requiring to be started within an X11 session. I think giving that flexibility to the root user for all users is a good thing.
I have a synaptics touchpad but I've always used evdev/mouse on it. Now, as far as the old synaptics driver is concerned, this is a WONTFIX because it's going to get treecleaned. Could anyone enlighten me on synclient/syndaemon so we can act on this bug? Thanks
The init script is gone from both portage and the x11 overlay (without bumps). As for actually running syndaemon, upstream told me that now Gnome is able to pick up syndaemon's presence and run it. I don't know if that's configurable somehow, but that's something to look into. Closing fixed. Thanks
