[Touch-packages] [Bug 1814261] Re: gpm prevents loging to the console: spurious “Enter” events seems inserted

2019-02-04 Thread Alexis Wilke
I rebooted on Ubuntu 16.04 (4.4.0-142-generic) and it worked as expected once gpm was turned off. I used the following command to prevent gpm from starting on a reboot and messing up the login screen: sudo systemctl mask gpm -- You received this bug notification because you are a member of Ubun

[Touch-packages] [Bug 1814261] Re: gpm prevents loging to the console: spurious “Enter” events seems inserted

2019-02-04 Thread Alexis Wilke
I have the exact same problem on Ubuntu 16.04 (vmlinuz-4.4.0-142-generic). I will try to turn off GPM and see how my console functions without it. What a surprise though! Not being able to log in the simplest console. Not something I've seen in ages... -- You received this bug notification beca

[Touch-packages] [Bug 1779583] Re: cron do_command.c attempts a fork() without testing for errors

2018-07-02 Thread Alexis Wilke
** Tags removed: trusty ** Tags added: xenial ** Description changed: The do_command.c file calls fork() twice. For the first fork(), the possibility for an error is checked properly and an error emitted (see https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1702785 for an example

[Touch-packages] [Bug 1779583] Re: cron do_command.c attempts a fork() without testing for errors

2018-07-01 Thread Alexis Wilke
I guess I should attempt to compile before submitting a patch. Some brackets were required in one of the cases. ** Patch added: "Compiling fix to second fork() in child_process()" https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1779583/+attachment/5158458/+files/do_command-2.patch -- You

[Touch-packages] [Bug 1779583] Re: cron do_command.c attempts a fork() without testing for errors

2018-07-01 Thread Alexis Wilke
** Description changed: The do_command.c file calls fork() twice. - For the first for(), the possibility for an error is checked properly + For the first fork(), the possibility for an error is checked properly and an error emitted (see https://bugs.launchpad.net/ubuntu/+source/cron/+bug/

[Touch-packages] [Bug 1702785] Re: High memory and "can't fork" on heavy long-lived cron daemon

2018-07-01 Thread Alexis Wilke
Actually, an immediate fix for you guys may be to make sure that there is some *input_data. I have no clue what that means in terms of administrative setup, though. But maybe someone else can help in that area. The really bad statement looks like this: if (*input_data && fork() == 0) {

[Touch-packages] [Bug 1702785] Re: High memory and "can't fork" on heavy long-lived cron daemon

2018-07-01 Thread Alexis Wilke
I found a bug in the code as described in this issue: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1779583 The bug would not prevent the error you're seeing, however, there is a second fork() which, if it fails, will block that part of cron, which would therefore leak. So if it happens "on

[Touch-packages] [Bug 1779583] Re: cron do_command.c attempts a fork() without testing for errors

2018-07-01 Thread Alexis Wilke
This may be one solution to the problem reported here: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1702785 Because when the second fork() fails, the cron process waits for 2 children, one of which doesn't even exist and thus cron is stuck with "a ton" of memory allocated. This would also

[Touch-packages] [Bug 1779583] [NEW] cron do_command.c attempts a fork() without testing for errors

2018-07-01 Thread Alexis Wilke
Public bug reported: The do_command.c file calls fork() twice. For the first for(), the possibility for an error is checked properly and an error emitted (see https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1702785 for an example when that happens: message is "can't fork".) This first fork()

[Touch-packages] [Bug 1309535] Re: Running without pam-kwallet installed issues a warning in auth.log

2014-11-29 Thread Alexis Wilke
There is information about KWallet. https://wiki.archlinux.org/index.php/KDE_Wallet It is marked as optional because it is allowed to fail as it does when you are running with Gnome (unity uses Gnome by default). So this is not a bug. You make comment out the lines as shown in #19 but you may reg